বৈশিষ্ট্য শাখাগুলি থেকে মাস্টারে মার্জ হওয়ার আগে কোড পর্যালোচনার কৌশল


22

আমি এবং আমার টিম বৈশিষ্ট্যগুলি শাখা ব্যবহার করি (গিট সহ)। আমি ভাবছি যে মাস্টারে মার্জ হওয়ার আগে কোড পর্যালোচনার জন্য সেরা কৌশলটি।

  1. আমি মাস্টারের কাছ থেকে একটি নতুন শাখা চেকআউট করছি, এটিকে fb_ # 1 বলি
  2. আমি কয়েকবার প্রতিশ্রুতিবদ্ধ এবং এটি আবার মাস্টারের সাথে একীভূত করতে চাই
  3. আমি মার্জ করার আগে কারও একটি কোড পর্যালোচনা করার কথা

এখন 2 টি সম্ভাবনা রয়েছে:

1 ম

  1. এটিকে যতটা সম্ভব আপ-টু-ডেট করার জন্য আমি মাস্টারকে fb_ # 1 ( মাস্টার হিসাবে fb_ # 1 নয় ) সাথে একীভূত করি
  2. একজন সতীর্থ মাস্টার হেড এবং fb_ # 1 মাথার মধ্যে পরিবর্তনগুলির পর্যালোচনা করে
  3. যদি fb_ # 1 ঠিক থাকে তবে আমরা fb_ # 1 কে মাস্টার হিসাবে মার্জ করি
  4. পেশাদাররা: পর্যালোচনায় কোনও অপ্রচলিত কোড নেই
  5. কনস: যদি অন্য কেউ "1" এর মধ্যে কিছু মিশে যায় Cons এবং "২" তার পরিবর্তনগুলি পর্যালোচনাতে উপস্থিত হয়, যদিও সেগুলি অন্য পর্যালোচনার অন্তর্ভুক্ত।

2nd

  1. সতীর্থ চেকআউট পয়েন্টের মধ্যে পরিবর্তনগুলি পর্যালোচনা করে (গিট মার্জ-বেস মাস্টার fb_ # 1) এবং fb_ # 1 মাথা
  2. পেশাদাররা: আমরা বৈশিষ্ট্য শাখায় কাজ করার সময় ঠিক কী পরিবর্তন হয়েছিল তা দেখতে পাই
  3. কনস: কিছু অপ্রচলিত কোড পর্যালোচনাতে উপস্থিত হতে পারে।

আপনি কোন উপায়ে ভাল এবং কেন মনে করেন ? সম্ভবত আরও একটি উপযুক্ত পদ্ধতির আছে?

উত্তর:


9

আপনার 1 ম বিকল্পের বৈচিত্র রয়েছে:

  1. এটিকে যতটা সম্ভব আপ-টু-ডেট করার জন্য মাস্টারকে Fb_ # 1 (মাস্টার হিসাবে fb_ # 1 নয়) মার্জ করুন
  2. সতীর্থ আপনার সাথে একত্রিত হয়ে এফবি_ # 1 প্রধানের সাথে মাস্টারের মধ্যে পরিবর্তনের পর্যালোচনা করে
  3. যদি fb_ # 1 ঠিক থাকে তবে আমরা fb_ # 1 কে মাস্টার হিসাবে মার্জ করি
  4. মার্জটি ঠিক আছে তা পরীক্ষা করে দেখুন

যেমন।

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

কোথায়:

  • মা মাস্টার এবং fb_ # 1 এর পূর্বপুরুষ।
  • fn আপনার শাখায় শেষ পরিবর্তন
  • মিমি হ'ল সেই প্রতিশ্রুতি যা আপনি যখন আপনার শাখায় একীভূত হয়েছিলেন ( এফএম দিচ্ছেন ) তখন মাস্টার / হেড ছিলেন ।

সুতরাং, আপনি আপনার প্রাথমিক পর্যালোচনাতে মিমি এবং এফএম তুলনা করুন এবং তারপরে দ্রুত পদক্ষেপের জন্য এমএফ মার্জ করার পরে তা পরীক্ষা করে দেখুন যে 1-3- এর পদক্ষেপের সময় মাস্টারটিতে কোনও উল্লেখযোগ্য পরিবর্তন ঘটে না। প্রাথমিক পর্যালোচনার পক্ষে এটির পক্ষে সমস্ত মতামত এবং কোনটিই নয়।

এটি ধরে নিয়েছে যে মাস্টারকে ধাক্কা দেওয়া পরিবর্তনগুলির স্বাভাবিক ফ্রিকোয়েন্সিয়ের সাথে তুলনা করে পর্যালোচনাটি দ্রুত হয়, তাই এফএম -> এমএফ প্রায়শই একটি দ্রুত এগিয়ে যায়।

যদি তা না হয় তবে যে কোনও কারণেই হোক না কেন, কনসগুলি প্রাথমিক পর্যালোচনা থেকে মার্জ-পরবর্তী পর্যালোচনায় চলে যাবে এবং কেবলমাত্র মাস্টারের সাথে সরাসরি মার্জ হওয়া এবং সেখানে একক পর্যালোচনা করা সহজতর হতে পারে।


"আপনি যে বিন্দুটি একীভূত করেছিলেন" আমি কীভাবে পেতে পারি? "গিট মার্জ-বেস মাস্টার হেড" ঠিক আছে, বা এটি প্রাথমিক ব্রাঞ্চিং পয়েন্টটি প্রদর্শন করবে?
আন্দ্রেজ গিস

আপনি মার্জ করার পরে ইচ্ছাকৃতভাবে মাস্টার আপডেট না করলে এটি কেবল মাস্টার হবে।
বেহুদা

হ্যাঁ, তবে অন্য কেউ যদি এটি আপডেট করে তবে কীভাবে পয়েন্ট পাবেন?
আন্দ্রেজ গিস

আপনি যখন এফবি শাখায় থাকবেন তখন ব্যবহার করুন git show HEAD। যেহেতু এটি মার্জ কমিট এফএম হবে, তাই এটি পিতামাতার উভয়ের তালিকা করবে । সুতরাং, আপনি মিমি হ্যাশ আছে । বিকল্পভাবে, আপনি তুচ্ছভাবে পিতামাতাকে বা অন্য কোনও গিট ব্রাউজারে দেখতে পারেনgitk
অকেজো

13

3 য়

  • আপনি রি-বেসের ফলে উভয় এটিকে আপ টু ডেট মাস্টার উপর শাখা এবং পরিবর্তন আলাদা রাখার।

    এটি শাখার একটি নতুন ইতিহাস তৈরি করে। এটি নতুন আইডি সহ নতুন সংস্করণ হবে যা একই বিষয়বস্তুতে থাকবে তবে সর্বশেষতম মাস্টার থেকে নেওয়া হবে এবং এটি পুরানো সংশোধনগুলির সাথে লিঙ্ক করবে না। পুরানো সংশোধনীগুলি এখনও "রেফলগ" এ অ্যাক্সেসযোগ্য যদি আপনার সেগুলি উল্লেখ করা প্রয়োজন যেমন আপনি বিরোধী সমাধানে ভুল করেছেন বলে মনে করেন। তা ছাড়া তারা মূল্যহীন। গিট ডিফল্টরূপে 3 মাস পরে রিফ্লগ ছাঁটাই করে এবং পুরানো সংশোধনগুলি ত্যাগ করে।

  • আপনি পরিবর্তনগুলি পুনরায় অর্ডার করতে, সম্পাদনা করতে এবং সাফ করার জন্য ইন্টারেক্টিভ রিবেস ( git rebase -iএবং git commit --amend) ব্যবহার করেন যাতে প্রতিটি যুক্তিসঙ্গতভাবে বন্ধ থাকে।

    এটি আবার নতুন ইতিহাস তৈরি করে, এবার যুক্ত হওয়া বেনিফিটের সাথে আপনি পর্যালোচনার সময় সর্বাধিক বোধ করতে পরিবর্তনগুলি পুনর্গঠন করতে পারবেন।

  • পেশাদাররা:

    • পর্যালোচনাতে কোনও অপ্রচলিত কোড নেই
    • বৈশিষ্ট্য শাখায় কাজ করার সময় আমরা ঠিক কী পরিবর্তন করেছি তা দেখতে পাচ্ছি
  • কনস:
    • আরও কিছু কাজ
    • ইতিমধ্যে মার্জ হওয়া বা আপনি ভাগ করে নেওয়া এবং প্রাপক এটি পুনরায় চালু হওয়ার প্রত্যাশা করে না এমন কোনও কিছু পুনরায় চালু না করার জন্য আপনাকে যত্ন নিতে হবে।

সাধারণত অতিরিক্ত কাজের অর্থ আপনি প্রথমে কোডটি নিজের সম্পর্কে পুরোপুরি পর্যালোচনা করুন এবং এটিও অনেক সমস্যার মুখোমুখি হবে।

লিনাক্স এবং গিট এটিই করে। এবং 20 থেকে 25 টি প্যাচগুলি পর্যালোচনার জন্য জমা দেওয়া হচ্ছে এবং সেই প্রকল্পগুলিতে বেশ কয়েকবার পুনর্লিখন করা অস্বাভাবিক নয়।

প্রকৃতপক্ষে লিনাক্স প্রকল্পের প্রথম থেকেই এটি করেছিল যখন তাদের পছন্দগুলির সংস্করণ নিয়ন্ত্রণটি টার্বল এবং প্যাচ ছিল। যখন বহু বছর পরে লিনাস গিট তৈরির উদ্দেশ্যে যাত্রা করেছিল, তখন rebaseআদেশটি বাস্তবায়নের প্রধান কারণ এটি ছিল এবং এটি ইন্টারেক্টিভ বৈকল্পিক। এছাড়াও এটির কারণে গিট লেখক এবং প্রতিশ্রুতিবদ্ধের পৃথক ধারণা রয়েছে । লেখক যিনি প্রথমে সংশোধন এবং প্রতিশ্রুতিবদ্ধটি তৈরি করেছিলেন তিনি হলেন যিনি সর্বশেষে এটি স্পর্শ করেছিলেন। যেহেতু লিনাক্স এবং গিট উভয় ক্ষেত্রেই প্যাচগুলি এখনও ইমেলের মাধ্যমে জমা দেওয়া হয়, তাই দু'টি প্রায় একই ব্যক্তি হয় না।


1
+1 এছাড়াও পরবর্তী পদক্ষেপগুলি সম্পর্কে জিজ্ঞাসা করেনি, তবে আপনার বৈশিষ্ট্যকে মাস্টার হিসাবে আনতে আপনি এমন একটি ব্যবহার করতে পারেন merge --no-ffযা স্পষ্ট করে দেবে যে শাখার বৈশিষ্ট্যটি পরিবর্তে বাকী
কমিটগুলিতে

@ স্টিজন: --no-ffএর উত্থান-পতন রয়েছে। আমি ব্যক্তিগতভাবে এটি যে কোনও কিছুর চেয়ে বেশি শব্দ পাই। YMMV।
জানু হুডেক

হ্যাঁ এটি অগ্রাধিকারের বিষয় .. মাস্টার যদি সাধারণত পরিষ্কার এবং সরল থাকে তবে আলাদা 'বুদবুদ' থাকা বড় বৈশিষ্ট্যগুলিকে আমি আপত্তি করি না। মাস্টার যদি ইতিমধ্যে কোনও জগাখিচুড়ি হয় তবে নো-
এফ

আমি চাই একটি উত্তর চেয়ে মোড গ্রহণ করতে পারে। একটি হাইব্রিড দ্রবণ আদর্শ হবে। রিবেস ব্যবহার করা এবং ব্রাঞ্চ পয়েন্টের সাথে তুলনা করার চেয়ে ভাল যাওয়ার উপায় মনে হয়।
আন্দ্রেজেজ গিস

দ্বিতীয় কন - আমি মনে করি না আপনি যদি ইতিমধ্যে কারও সাথে নিজের শাখা ভাগ করে নিয়েছেন তবে আপনি এটি করতে পারবেন। আপনি যখন ইতিহাস পুনর্লিখন করবেন সেখানে অসঙ্গতি থাকবে।
ষাট ফুটারসুডে

4

আসলে তৃতীয় সম্ভাবনা রয়েছে — এবং সম্ভবত অন্যরা প্রচুর পরিমাণে আছে, যেহেতু জিআইটি একটি এসসিএম পদ্ধতি প্রয়োগের চেয়ে এসসিএম কাঠামোর বাস্তবায়ন। এই তৃতীয় সম্ভাবনা উপর ভিত্তি করে rebase

rebaseএলেবেলে subcommand (আপনার বিষয় শাখা ডগা আপনার শাখাবিন্যাস বিন্দু থেকে সাধারণত কমিট একটি সিরিজ লাগে topic) এবং তাদের অন্য কোথাও রিপ্লে (সাধারণত আপনার ইন্টিগ্রেশন শাখা ডগা, যেমন এ master)। rebaseSubcommand নতুন করে, যা একটি ফর্ম পর্যালোচনা করা সহজ যে করে সাজানোর সুযোগ দেয় উৎপন্ন হয়। এটি প্রতিশ্রুতির একটি নতুন সিরিজ দেয় যা আগে topicব্যবহৃত একই রকম ছিল তবে ইন্টিগ্রেশন শাখার শীর্ষে মূলের প্রদর্শিত হয়। এই নতুন শাখাটিকে এখনও topicজিআইটি কল করে, যাতে পুরানো রেফারেন্সটি ফেলে দেওয়া হয়। আমি অনানুষ্ঠানিকভাবে topic-0আপনার শাখার মূল অবস্থা topic-1এবং তার বিভিন্ন রিফ্যাক্টরিংয়ের উপর লেবেল করি ।

আপনার topicশাখার জন্য আমার পরামর্শটি এখানে :

  1. (ঐচ্ছিক পদক্ষেপ) ইন্টারেক্টিভ পদ্ধতিতে আপনার বিষয়ের শাখা রি-বেসের ফলে topicতার শাখাবিন্যাস বিন্দুতে (দেখুন --fixupজন্য বিকল্প commitএবং -iএবং --autosquashদিকের বিকল্পগুলি rebase), যা আপনি একটি উপায় পর্যালোচনা করা সহজ যে আপনার করে পুনর্লিখন করার সুযোগ দেয়। এটি একটি শাখায় ফলাফল topic-1

  2. আপনি আপনার ইন্টিগ্রেশন শাখার শীর্ষে আপনার টপিক শাখাটি রিবাজ করেন, মার্জ করার অনুরূপ, তবে কেবল একটি সফটওয়্যার ইঞ্জিনিয়ারিং শিল্পকর্ম যা একীভূতকরণের সাথে ইতিহাসকে "দূষিত করে না"। এটি একটি শাখায় ফলাফল topic-2

  3. topic-2এমন সতীর্থকে প্রেরণ করুন যা এটির টিপের বিপরীতে পর্যালোচনা করে master

  4. যদি topic-2ঠিক থাকে তবে মাস্টারটিতে এটি মার্জ করুন।

দ্রষ্টব্য: যে শাখাগুলি - যেখানে শাখাটি প্রতিশ্রুতিবদ্ধ গাছকে বোঝায় - সমস্তগুলি জিআইটি দ্বারা একই বলা হবে, সুতরাং, প্রক্রিয়া শেষে, কেবল শাখার topic-2জিআইটিতে একটি নাম থাকবে।

পেশাদাররা:

  • পর্যালোচনাতে কোনও অপ্রচলিত কোড নেই।
  • কোনও উত্সাহী "বিদেশী সংশ্লেষ" পর্যালোচনা নেই (আপনি প্রথমে বর্ণিত ঘটনা)।
  • পুনর্লিখনের সুযোগটি একটি পরিষ্কার উপায়ে কমিট করে।

কনস:

  • এক শাখা পরিবর্তে topic-0, সেখানে তিনটি শাখা নিদর্শন হয় topic-0, topic-1এবং topic-2যে নির্মিত গাছ কমিট হবে। (যদিও যে কোনও সময়ে, তাদের মধ্যে কেবল একটিরই জিআইটিতে নাম রয়েছে))

আপনার 1 ম দৃশ্যে - যদি কেউ "1" এর মধ্যে কোনও কিছু একীভূত করে এবং "২" বলতে শাখা পয়েন্ট তৈরির সময় এবং যখন আপনি একত্রীকরণের সিদ্ধান্ত নেন তখন সময়কে বোঝায়। এই পরিস্থিতিতে - যদি কেউ "1" এর মধ্যে কোনও কিছু একীভূত করে এবং "২" বলতে রিবেস এবং সংযুক্তির মধ্যে বিস্তৃত সময়কে বোঝায় যা সাধারণত খুব কম থাকে। এইভাবে আমি যে দৃশ্যের সরবরাহ করি masterতাতে আপনি আপনার কর্মপ্রবাহকে লক্ষণীয়ভাবে বিরক্ত না করে একীভূত হওয়ার সময়টির জন্য শাখাটি "লক" করতে পারেন , যখন এটি 1 ম দৃশ্যে অযৌক্তিক।

আপনি যদি পদ্ধতিগত কোড পর্যালোচনা করছেন, তবে পর্যাপ্ত উপায়ে (alচ্ছিক পদক্ষেপ) কমিটগুলি পুনরায় সাজানো সম্ভবত একটি ভাল ধারণা।

মধ্যবর্তী শাখার নিদর্শনগুলি পরিচালনা করা কেবলমাত্র যদি আপনি সেগুলি সংগ্রহস্থলের মধ্যে ভাগ করে থাকেন তবে একটি অসুবিধা উপস্থাপিত হয়।


নেই topic-0, topic-1এবং topic-2শাখা থাকা উচিত । দ্বিতীয় রিবেসটি সম্পূর্ণ, পূর্ববর্তী সংস্করণটি অপ্রাসঙ্গিক। তাই সেখানে হবে topic@{1}, topic@{2}, topic@{yesterday}, topic@{3.days.ago}ইত্যাদি আপনার গুঁতা ক্ষেত্রে আপনাকে খুঁজে আপনি রি-বেসের ফলে মধ্যে দ্বন্দ্ব রেজল্যুশন মাতাল সংরক্ষণ করুন।
জানু হুডেক

তিনটি শাখা বিদ্যমান, তবে কোনও নাম নেই (রেফ নেই) ref হয়তো আমার এই জোর দেওয়া উচিত।
মাইকেল লে বারবিয়ার গ্রেনওয়াল্ড

পুনর্বিবেচনাগুলি বিদ্যমান এবং রিফ্লগ এন্ট্রি দ্বারা চিহ্নিত করা হয়। তবে শাখা হিসাবে কেবল একটি topic,। কারণ গিটের শাখা কেবল নাম।
জানু হুডেক

কীভাবে এটি আমাকে "বিদেশী সংযুক্তি" থেকে বাঁচায়? আমি যদি কোনও সতীর্থকে টপিক -২ পাঠানোর পরে যদি কেউ মাস্টারকে একীভূত করে এবং সতীর্থ তার সাথে মাস্টারের পরামর্শের বিপরীতে পর্যালোচনা করে তবে কী হবে?
Andrzej Gis

@JanHudec যে কোন সময়ে, সেখানে শুধুমাত্র একটি শাখা বলা হয় topicএলেবেলে এটা সবসময় শাখা এক (একটি শাখা হিসেবে এলেবেলে রেফারেন্স হিসেবে নয়, গাছ কমিট) আমি লেবেল করা হয়, topic-0, topic-1, topic-2
মাইকেল লে বার্বিয়ার গ্রেনওয়াল্ড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.