অন্য শাখার উপর নির্ভরশীলতা সহ একটি শাখায় কাজ করা যা পর্যালোচনা করা হচ্ছে

Question

গিট কীভাবে নীচের দৃশ্যপট মোকাবেলা করতে সহায়তা করে:

আমার একটি টাস্কটি 2 ভাগে বিভক্ত হয়েছে: ব্যাকএন্ড টাস্ক এবং ফ্রন্টএন্ড টাস্ক। আমি ব্যাকএন্ডের পরিবর্তনগুলি মার্জ করার জন্য একটি টান অনুরোধ করব এবং এটি সংযুক্ত হওয়ার জন্য অপেক্ষা করুন (এবং প্রতিক্রিয়াটির ঠিকানা দিন)। অপেক্ষা করার সময়, আমি সত্যিই সীমান্তের পরিবর্তনগুলিতে কাজ করতে পারি না কারণ এটি ব্যাকএন্ড পরিবর্তনের উপর নির্ভর করে এবং সেগুলি এখনও মাস্টার শাখায় উপলভ্য নয়।

এখনও পর্যালোচনা চলাকালীন ব্যাকএন্ড পরিবর্তন শাখা থেকে অগ্রণী পরিবর্তন শাখায় পরিবর্তনগুলি টানানোর সর্বোত্তম উপায় কী?

Comments

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

— হের ডার্ব

@ হার্ডার্ব ওহ মিষ্টি গ্রীষ্মের শিশু ...

— বাগানের মাথায়

আপনি কেন এটি এখনও-পর্যালোচিত না হওয়া ব্যাকএন্ড কোডের বিরুদ্ধে লিখতে পারবেন না?

— ব্যবহারকারী 253751

আপনার দলে এই পরিস্থিতিটি পরিচালনা করার জন্য কি একরকম সম্মতিযুক্ত কৌশল আছে? যদি তা না হয়, তবে আপনার পক্ষে এই জাতীয় কোনও বিষয়ে একমত হওয়া উচিত, কারণ এটি মোটামুটি সাধারণ পরিস্থিতি।

— রাদু মুর্জিয়া

কেউ নেই. এই কারণেই আমি এই প্রশ্নটি জিজ্ঞাসা করেছি। আমি খুব ভাল পরামর্শ পেয়েছি। আমি পরামর্শগুলি চেষ্টা করে দেখব এবং কীভাবে তারা আমার জন্য কাজ করে।

— sul4bh

Answer 1

আমার মাঝে মাঝে খুব সমস্যা হয়। গিট খুব নমনীয়। এখানে এটি করার একটি উপায়।

আপনার প্রথম শাখা featureAপর্যালোচনার জন্য প্রস্তুত।

আপনার দ্বিতীয় শাখাটি featureBবিকাশে রয়েছে এবং featureAশাখার কোডের উপর নির্ভর করে ।

featureAশাখায় শাখাটি মার্জ করুন featureB।

আপনি যদি featureAশাখায় পরিবর্তন করেন তবে পরিবর্তনগুলি সংযুক্ত করার জন্য আপনার আবার শাখাটি featureAশাখায় মার্জ করা উচিত featureB।

আপনার featureAপ্রথমে মূল ট্রাঙ্কে মার্জ করার বিষয়টিও নিশ্চিত করা উচিত , অন্যথায় আপনি যখন featureBমুখ্য ট্রাঙ্কে মার্জ করবেন তখন অজান্তে আপনিও মার্জ করবেন featureA। একবার featureAমুখ্য ট্রাঙ্কে একীভূত হওয়ার পরে আপনি কেবল featureAশাখার হাত থেকে মুক্তি পেতে পারেন featureBএখন কেবল প্রধান ট্রাঙ্কের উপর নির্ভর করে।

আমি এটিকে পছন্দ করি যখন আমার বৈশিষ্ট্যগুলি শাখাগুলি একে অপরের উপর নির্ভর করে না তবে কখনও কখনও তারা তা করে এবং আপনাকে এটির সাথে রোল করতে হবে।

Comments

এইবার বুঝতে পারছি. এটি যদি প্রয়োজন featureAহয় featureBতবে মার্জটি পূর্বাবস্থায় ফেলার অনুমতি দেয় ?

— sul4bh

পূর্বাবস্থায় ফিরে আসা অপারেশন নেই তবে @ 9000 হিসাবে উল্লেখ করা হয়েছে, আপনি একটি নতুন শাখা তৈরি করতে পারবেন এবং চেরি featureAযদি আপনার আবার শুরু করতে হয় তবে আপনি যে কমিটগুলি চান তা বেছে নিতে পারেন। গিট শাখাগুলিকে ডিসপোজেবল হিসাবে ভাবা ভাল। এগুলি সস্তা এবং সহজ, আপনি সর্বদা একটি নতুন শাখা তৈরি করতে পারেন। এমনকি আপনি featureBযদি নিজের সম্পর্কে নিশ্চিত নন এমন কিছু নিয়ে খেলতে চান, এবং তারপরে এটি কার্যকর না হয় তবে এটিকে স্ক্র্যাপ করুন বা যদি তা না করে তবে এটি আবার আপনার featureBশাখায় একীভূত করতে পারেন তবে আপনি আপনার শাখাটি থেকে একটি পরীক্ষা শাখাও তৈরি করতে পারেন।

— ম্যাট

সংশ্লেষ এমন গণ্ডগোল তৈরি করবে যা রোল-ব্যাক করা কঠিন (অসম্ভব নয়)। আমি চেরি-পিক বা রিবেসটি পুনরায় সংগ্রহ করব (অর্থাত: বৈশিষ্ট্য বি এর ভিত্তিতে ফিচার এ-তে সমস্ত কিছু চেরি-পিক)। 9000 এর উত্তর দেখুন।

— পিয়েরে.সাসৌলাস

এটি একটি জটিল ইতিহাস তৈরি করে যা বহু বছর ধরে একটি সমস্যা হয়ে দাঁড়াবে যখনই কেউ বুঝতে চাইবে ফিচারএ এবং বৈশিষ্ট্য বি এর জন্য কোন কোডটি পরিবর্তন করা হয়েছিল

— আইয়ান

যদি ফিচারএ আপডেট হয় তবে ফিচারবি'কে একীভূত না করে রিবেস করা উচিত

— লিন্ডন হোয়াইট

Answer 2

ধরুন, মার্জ করা এড়িয়ে যান

এই পদ্ধতির জন্য, আপনি কি না আপনার একত্রীকরণ করতে চান feature_aমধ্যে feature_bবারবার।

অন্যান্য উত্তরে রিবেসিংয়ের কথা উল্লেখ করা হয়েছে তবে কেবল জিনিসগুলি রিবেস করার জন্য master। আপনার ক্ষেত্রে আপনি যা করতে চান তা হ'ল:

• আপনার feature_bথেকে শুরু করুন feature_a, যেমন:

  git checkout feature_a
  git checkout -b feature_b
  

• যখনই feature_aসময় পরিবর্তনগুলি এটা অপেক্ষা করছে মধ্যে মিশে গিয়ে তৈরি করতে master, আপনি রি-বেসের ফলে feature_b এটা করুন:

  ... commit something onto feature_a ...
  git checkout feature_b
  git rebase feature_a
  

• অবশেষে, এর সাথে feature_aএকত্রীকরণ হওয়ার সাথে সাথে masterআপনি কেবল নতুন masterএবং নতুন বার feature_aএটিতে সর্বশেষে ফিরে আসবেন :

  git checkout master
  git pull origin master
  git checkout feature_b
  git rebase --onto master feature_a feature_b
  

  এই চূড়ান্ত রিবেসটি feature_aকমিট থেকে ঝুঁকছে এমন সমস্ত অঙ্গীকারকে কল্পনা করবে (যা এখন এটি অপ্রাসঙ্গিক কারণ এটিতে একীভূত হয়ে গেছে master) ডানদিকে master। আপনার feature_bএখন থেকে একটি সরল, মানক শাখা master।

সম্পাদনা: মন্তব্য থেকে অনুপ্রাণিত, একটু মাথা আপ: আপনি যদি কিছু পরিবর্তন করতে হয় যা উভয় বৈশিষ্ট্যকেই প্রভাবিত করে, তবে অবশ্যই এটিতে নিশ্চিত হন feature_a(এবং তারপরে যেমন দেখানো হয়েছে তেমন পুনরায়)। উভয় শাখায় এটি দুটি পৃথক কমিটে তৈরি করবেন না , এমনকি লোভনীয় হলেও; feature_aইতিহাসের অংশ হিসাবে feature_b, দুটি ভিন্ন কমিটের একক পরিবর্তন হওয়া শব্দার্থগতভাবে ভুল হবে এবং সম্ভবত দ্বন্দ্ব বা অযাচিত কোডের "পুনরুত্থান" হতে পারে, পরে।

Comments

feature_aএকাধিকবার রিবেসিংয়ের পরে, আপনি পরে সমস্যার মধ্যে পড়তে পারেন, যখন feature_aইতিমধ্যে নিজেই পুনঃনির্মাণ করা হয়েছে। চলমান ফলস্বরূপ git checkout feature_b; git rebase feature_aআপনি দ্বন্দ্ব পেতে পারেন বা কমিটস যুক্ত কিছু মজার কমিটগুলি এর নতুন পরিবর্তনগুলিকে ফিরিয়ে আনতে পারে feature_a। --interactiveঅন্যান্য শাখার পুরাতন সংস্করণ থেকে নেওয়া কমিটগুলি ব্যবহার করে এবং এড়িয়ে যাওয়ার মাধ্যমে এটি সাধারণত সমাধানযোগ্য হয় (সম্প্রতি আমি বেশ কয়েকবার এটি করতে হয়েছিল)।

— মার্টিনাস

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

— AnoE

আমার ধারণা, mergeএকই রকম বা খারাপ সমস্যা হবে (একটি সংঘাতের অযাচিত পরিবর্তন হওয়ার মতো খারাপ নয়)। আমি অনেকগুলি সম্পর্কযুক্ত পরিবর্তন (যৌক্তিকভাবে একটি পৃথক শাখার অন্তর্ভুক্ত) দ্বারা পূর্ববর্তী চাওয়া পরিবর্তনের ক্রম হিসাবে একটি শাখা দেখি । একই শাখার সাথে বারবার প্রত্যাবর্তন করার সময়, আমি সর্বদা সম্পর্কযুক্ত পরিবর্তনগুলি অপসারণ করি কারণ আমি জানি তারা যেভাবেই আসবে (সম্ভবত একটি আপডেট আকারে) এবং এটি ঠিক কাজ করে।

— মার্টিনাস

@ মাআর্টিনাস, আমি এ সম্পর্কে একটি ছোট সংযোজন যুক্ত করেছি (ধারাবাহিকভাবে পরিবর্তন করতে যা উভয় শাখায় কেবল বেস শাখায় যেতে হবে, দুটি পৃথক কমিট নয়)।

— AnoE

চমৎকার কৌশল। আমি এটি সবসময় পাশাপাশি করি। git rebase --onto

— এফটিডব্লিউ

Answer 3

আপনার ইতিমধ্যে একটি শাখা রয়েছে যার উপর আপনার প্রতিটি বৈশিষ্ট্য শাখা নির্ভর করে এবং যা পরিবর্তন করে চলেছে। এটি বলা হয় master।

কোনও বৈশিষ্ট্য শাখার সাথে সুসংগত থাকার জন্য সাধারণ উপায় এর শীর্ষেmaster থাকা । যখন পরিবর্তন হয়, আপনি সাধারণত আপনার শাখার কার্যকরী ডিরেক্টরিতে থাকেন।mastergit fetch origin master:master && git rebase master

আপনি অন্য বৈশিষ্ট্যযুক্ত শাখার সাথে খুব একই জিনিসটি করতে পারেন: এটিকে এনে রাখা এবং এটির উপরে প্রত্যাবর্তন চালিয়ে যান।

তাহলে কিছু কারণে, আপনি কি অন্য কিছু শাখা আপনার পরিবর্তনগুলি সরানো প্রয়োজন করব, আপনি চেরি-বাছাই করতে পারেন আপনার করে, যাতে অন্যান্য শাখা এর করে মিশিয়ে না হয়।

Comments

তবে আমি মনে করি দৃশ্যপটটি হ'ল বৈশিষ্ট্য-বি-তে কোড থাকা দরকার যা ফিচার-এ-তে রয়েছে, মাস্টার থেকে শাখা প্রশস্ত করা খুব সহায়ক হবে না। কোথায় শুরু করব? আমি কি বৈশিষ্ট্য-ক থেকে শাখা করে ফিচার-এ মাস্টারের সাথে পুনরায় সংহত না হওয়া পর্যন্ত সেগুলিকে সিঙ্কে রেখেছি এবং তারপরে মাস্টার থেকে ফিচার-বিতে পুনরায় ব্যবহার করব?

— সিনায়েস্টিক

@ সিনেস্টেথিক: আপনি অবশ্যই ভিত্তি feature-bস্থাপন করতে পারেন feature-aএবং feature-aপরিবর্তনের সাথে সাথে সময় মতো রিবেস করতে পারেন । এটি একটি বৃহত পরিবর্তনকে পর্যবেক্ষণযোগ্য করে তোলার একটি সাধারণ উপায়: এটিকে বিভক্ত করুন part-A(ভিত্তিক বন্ধ master), part-B(ভিত্তিক বন্ধ part-A), এবং প্রয়োজনে আরও অনেক কিছু। তারপরে প্রতিটি অংশের জন্য একটি টান অনুরোধ করুন, এবং পর্যালোচকদের আরও ছোট, যৌক্তিকভাবে গোষ্ঠীযুক্ত টুকরোগুলি দেখার জন্য সহজ সময় রয়েছে।

— 9000

আমি পিআর এর দিক দিয়ে পার্ট-বি এর সাথে পার্ট-বি বনাম পার্ট-বি দিয়ে মাস্টারের সাথে রিবেস করব কিনা তা বিবেচিত হবে? আমি শুধু নিশ্চিত করতে চাই যে আমার পরিবর্তনগুলি খণ্ড-বি পরিবর্তন হিসাবে অংশ-পরিবর্তনগুলি প্রদর্শন করছে না। এছাড়াও, আমি যদি বনাম পুনঃবাসটি একীভূত করি তবে কীভাবে পার্ট-বি পিআরকে প্রভাবিত করবে? যতবার আমি মনে করি আমি এর প্রভাবগুলি বুঝতে পারি, আমি কিছু আলাদা ফলাফল পেয়ে

— যাচ্ছি

Answer 4

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

একটি বৈশিষ্ট্য শাখা যা দীর্ঘকাল বেঁচে থাকে তার জন্য "পর্যালোচনা, কিউ, মার্জ- এর অংশ না হয়ে বৈশিষ্ট্য শাখায় দেব কাজের অংশ হিসাবে কোনও মার্জ বা শব্দার্থবিরোধের সাথে পুনর্মিলন করা নিশ্চিত করা" থেকে মাস্টার "প্রক্রিয়া)। সুতরাং আপনি এটি আপনার সামনের প্রান্তের শাখায় করেন, এবং যখন ব্যাকএন্ডের কাজটি মাস্টার হিসাবে গ্রহণ করা হয়ে যায়, আপনি একই রুট দ্বারা স্বয়ংক্রিয়ভাবে, তার পর্যালোচনা / গ্রহণযোগ্যতার অংশ হিসাবে ব্যাকএন্ডে করা হয়েছে এমন কোনও ছোটখাট পরিবর্তন পাবেন get মাস্টারে অন্য কোনও কোড পরিবর্তন পান।

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

যদি এটির সক্রিয় হয়ে যায় যে পুরো ব্যাকএন্ড শাখাটি পরিত্যাগ করা হবে এবং কখনই একত্রীকরণ করা হবে না (এটি মনে হচ্ছে এটি খুব বড় চুক্তি হবে যা খুব কমই ঘটেছিল), তবে আপনি হয় চেরি-বাছাই করে মাস্টার বন্ধ হয়ে আসা একটি নতুন শাখায় প্রতিশ্রুতিবদ্ধ হন ব্যাকএন্ড কাজ ছাড়াই বা আপনি বিপরীত কমিটস প্রয়োগ করেন যা সমস্ত ব্যাকএন্ড কোডটি ফ্রন্টএন্ড শাখায় সরিয়ে দেয়। তবে আমি দেখতে পাচ্ছি যে আপনি যে ব্যাকএন্ডটি ফেলে দিচ্ছেন সেটি কী প্রতিস্থাপন করবে এবং আপনি কী করবেন তা স্থির না করা পর্যন্ত আপনি অগ্রভাগের কাজটি থামিয়ে দেওয়ার সম্ভাবনা বেশি।

Answer 5

আমি এখানে সমস্যা দেখছি না।

আপনি ইতিমধ্যে আপনার masterশাখার সাথে প্রতিবার এটি রেখেছেন যা বৈশিষ্ট্যগুলি বিকাশকালে এবং পরে মার্জ হয়ে যাওয়ার সময় পরিবর্তিত হয়।

সুতরাং, আপনার কংক্রিট উদাহরণে, আপনি প্রথমে feature_xxx_backendশাখা তৈরি করেন এবং ব্যাকএন্ড পরিবর্তনগুলি বিকাশ করুন। এটি করা হয়ে গেলে, শাখাটি পর্যালোচনা করতে প্রস্তুত এবং masterপর্যালোচনাটি সম্পূর্ণ হওয়ার পরে এটিতে একত্রীকরণ করা হবে ।

সুতরাং, কেবল অন্য একটি শাখা শুরু করুন feature_yyy_frontend,। আপনি সম্ভবত সরাসরি ব্রাঞ্চ করতে চান feature_xxx_backend, যাতে আপনার ব্রাঙ্কে ইতিমধ্যে আপনার এই পরিবর্তনগুলি আসে। তারপরে শাখাটি ছিল কেবলমাত্র সীমা বৈশিষ্ট্য বিকাশ master।

যখন feature_xxx_backendশাখা পরিবর্তন হয়, উদাহরণস্বরূপ কারণ পর্যালোচনা চলাকালীন এমন কিছু বিষয় রয়েছে যাগুলি এড্রেস করা প্রয়োজন, কেবল এই পরিবর্তনগুলি করুন এবং সেগুলি feature_yyy_frontendশাখায় মার্জ করুন । তারপরে সামনের শাখায় চালিয়ে যান।

একবার ব্যাকএন্ড শাখার পর্যালোচনা শেষ হয়ে গেলে, এতে একীভূত হয়ে যায় master। এই মুহুর্তে, এটি বিজ্ঞতার কাজ হবে রি-বেসের ফলেfeature_yyy_frontend সম্মুখের শাখা master, যাতে সমালোচক শুধুমাত্র পর্যালোচনা করা প্রয়োজন নতুন যে পরিবর্তন এই শাখা অবদান master, এবং দরকার নেই ব্যাকএন্ড জন্য তৈরি পরিবর্তনগুলি (যা ইতিমধ্যে অনুমোদিত হয়েছে পুনরায় পর্যালোচনা )।

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

রিবেসিং (উপরে প্রস্তাবিত হিসাবে) সত্যই শক্তিশালী এবং পরিবর্তনগুলির পরিষ্কার লগ রাখতে সহায়তা করে, পর্যালোচনাগুলি আরও সহজ করে তোলে।

Answer 6

পলিগনোম যেমন উল্লিখিত হয়েছে, আপনি প্রকৃতপক্ষে মাস্টার্সের পরিবর্তে আপনার ফ্রন্টএন্ড শাখাটিকে আপনার ব্যাকএন্ড শাখায় মার্জ করতে পারেন। এমনকি আপনার কাছে এখনকার শাখা সেটআপ থাকা সত্ত্বেও আপনি সহজভাবে এটি করতে পারেন:

git checkout frontend
git merge backend

বা সহজভাবে

git merge backend frontend

যদিও মনে রাখবেন যে যদি ব্যাকএন্ড পরিবর্তনগুলি গ্রহণ না করা হয় এবং আরও কাজ করা প্রয়োজন হয়, তবে বিরোধগুলি এড়ানোর জন্য আপনাকে ব্যাকএন্ড থেকে আপডেটগুলি ফ্রন্টএন্ডে মার্জ করতে হবে। একবার পরিবর্তনগুলি মাস্টারে স্বীকৃত হয়ে গেলে, ব্যাকএন্ডের মার্জ কমিটগুলি থেকে মুক্তি পেতে আপনি মাস্টারের উপর আপনার ফ্রন্টএন্ডটি পুনর্বার করতে পারেন।

প্রযুক্তিগতভাবে আপনি রিবেস দিয়েও সবকিছু করতে পারেন, তবে এটি আপনার সীমানা শাখার অঙ্গীকারের ইতিহাসকে বিশৃঙ্খলা করবে। আমি যেখান থেকে আসছি, এটি খারাপ অভ্যাস হিসাবে বিবেচিত। YMMV

Comments

"অদ্ভুত যে কেউই উল্লেখ করেনি যে আপনি প্রকৃতপক্ষে মাস্টার্সের পরিবর্তে আপনার ফ্রন্টএন্ড শাখাটি আপনার ব্যাকএন্ড শাখায় মার্জ করতে পারবেন:" এটি ইতিমধ্যে উল্লেখ করা হয়েছে, যেমন আমার নিজের উত্তরে।

— বহুবিবাহ

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

— জোরিস মেজ

প্রকৃতপক্ষে, আমার উত্তরটি আপনাকে ব্যাকএন্ড থেকে সরাসরি শাখা করার পরামর্শ দেয় না, এটি কেবলমাত্র সায়েস যা সম্ভবত পথটি যেতে পারে (যেহেতু আপনি এই পরিবর্তনগুলি যে কোনও উপায়ে শাখা-প্রশাখায় মার্জেন)।

— পলিনোম

@ পোলিগনোম তখন আপনার উত্তরটি ভুল বুঝেছি। বিশেষ করে আপনার জন্য আপডেট হয়েছে :-)

— জোরিস মেজ

আমি জানি না কে এটিকে কমেছে, তবে দয়া করে আমাকে বলুন আমি কোথায় ভুল, তাই আমিও কিছু শিখতে পারি।

— জোরিস মাইস

Answer 7

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

আপনি যখন পৃথকভাবে পর্যালোচনা করতে চান (যেমন featureAএবং featureB) এর দুটি সেট বড় পরিবর্তন করেন তখন এমন একটি পিআর তৈরি করুন যা মার্জ করার উদ্দেশ্যে নয়, তবে কোনও পিওসি-তে প্রাথমিক প্রতিক্রিয়া সংগ্রহ করার জন্য featureA।

লোকেরা এটি দ্রুত পর্যালোচনা করতে সক্ষম হবে (এটি কেবলমাত্র একটি পোকা), এবং উদ্দেশ্যটি সাধারণ নকশা বা পদ্ধতির বৈধতা দেওয়া।

তারপরে, আপনি বৈশিষ্ট্য A তে কাজ চালিয়ে যেতে পারেন, এর জন্য একটি টান অনুরোধ তৈরি করতে এবং শাখা করতে এবং বি বৈশিষ্ট্য বিতে কাজ করতে পারেন

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