গিট কেন ডিফল্টরূপে দ্রুত-ফরোয়ার্ড মার্জগুলি সম্পাদন করে?


641

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

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

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

এই যুক্তি দিয়ে, আমি দ্রুত-ফরোয়ার্ড মার্জ করতে চাই না এবং এটি কেন ডিফল্ট তা দেখতে পাচ্ছি না। এটি সম্পর্কে এত ভাল কি?


38
দ্রষ্টব্য: স্যান্ডোফস্কি.কম / ব্লগ / গিট- ওয়ার্কফ্লো এইচটিএমএলও দেখুন এবং ' no-ffচেকপয়েন্টটি কমিট করে' এর সাথে ' ' এড়িয়ে চলুন যা দ্বিখণ্ডিত বা দোষ ভাঙবে।
ভোনসি

15
আপনি কি এক ব্যক্তি প্রকল্পে গিট ব্যবহার করে আফসোস করছেন?
HaveAGuess

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

7
@ কাওস সত্য, -no-ffখুব কমই খুব ভাল ধারণা, তবে মূল শাখায় কেবল একটি প্রতিশ্রুতি রেকর্ড করার সময় একটি বৈশিষ্ট্য-অভ্যন্তরীণ ইতিহাস রাখতে সহায়তা করতে পারে। এটি দীর্ঘ বৈশিষ্ট্যের ইতিহাসের জন্য অর্থবোধ করে, যখন আপনি সময়ে সময়ে এটির প্রধান অগ্রগতির অগ্রগতি ঘটাচ্ছেন।
ভোনসি

12
যাইহোক, আপনার "প্রশ্নটি কি [[রৈখিক শাখার ইতিহাস] অবৈতনিক বলে মনে হচ্ছে না?")। সোর্স কোড সিস্টেমটি ডিফল্ট হিসাবে ব্যবহার করার ক্ষেত্রে অযৌক্তিক কিছুই নেই। এটি পেশাদারিত্বের কথা নয়। আপনি শাখার কোন দর্শনটি আপনাকে সাবস্ক্রাইব করেছেন তা নির্ধারণের বিষয়ে এটি। উদাহরণস্বরূপ, @ ভনসি স্যান্ডোফস্কির নিবন্ধের সাথে লিঙ্ক করেছেন যেখানে তিনি চ্যাম্পিয়নরা দ্রুততর অগ্রাধিকার হিসাবে দ্রুত এগিয়ে ব্যবহার করছেন। সঠিক বা ভুল নয়, বিভিন্ন প্রসঙ্গে কেবল ভিন্ন দর্শন।
মার্পলসফট

উত্তর:


718

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

সতর্কতা : নন-ফাস্ট-ফরওয়ার্ডিংয়ের পাশাপাশি সম্ভাব্য পার্শ্ব প্রতিক্রিয়া রয়েছে। দয়া করে https://sandofsky.com/blog/git-workflow.html পর্যালোচনা করুন , দ্বিখণ্ডিত বা দোষ ভাঙার "চেকপয়েন্ট" কমিট করে "নো-এফএফ" এড়ান এবং সাবধানতার সাথে বিবেচনা করুন এটি আপনার ডিফল্ট পদ্ধতির হওয়া উচিত কিনা তা বিবেচনা করুন master

বিকল্প পাঠ
( এনভিএ ডটকম থেকে , ভিনসেন্ট ড্রিসেন , " একটি সফল গিট ব্রাঞ্চিং মডেল " পোস্ট করুন)

বিকাশে একটি সমাপ্ত বৈশিষ্ট্য অন্তর্ভুক্ত

সমাপ্ত বৈশিষ্ট্যগুলি আসন্ন প্রকাশে তাদের যুক্ত করতে বিকাশকারী শাখায় একীভূত করা যেতে পারে:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

--no-ffপতাকা সবসময় তৈরি করতে একটি নতুন অবজেক্ট কমিট একত্রীকরণ ঘটায়, এমনকি যদি একত্রীকরণ সঙ্গে ফাস্ট এগিয়ে সম্পাদনা করা যেতে পারে। এটি কোনও বৈশিষ্ট্য শাখার historicalতিহাসিক অস্তিত্ব সম্পর্কে তথ্য হারাতে বাধা দেয় এবং একসাথে সমস্ত বৈশিষ্ট্য যুক্ত করে এমন সমস্ত অঙ্গীকারকে দলবদ্ধ করে।

Jakub Narębski এছাড়াও উল্লেখ কনফিগmerge.ff :

ডিফল্টরূপে, বর্তমান কমিটের বংশধর এমন প্রতিশ্রুতি মার্জ করার সময় গিট অতিরিক্ত মার্জ কমিট তৈরি করে না। পরিবর্তে, বর্তমান শাখার টিপটি দ্রুত-ফরওয়ার্ড।
যখন সেট করা থাকে false, এই পরিবর্তনশীল গিটকে এই জাতীয় ক্ষেত্রে ( --no-ffকমান্ড লাইন থেকে বিকল্প দেওয়ার সমতুল্য ) একটি অতিরিক্ত মার্জ কমিট তৈরি করতে বলে ।
' only' এ সেট করা থাকলে , কেবলমাত্র এইমাত্র দ্রুত-ফরোয়ার্ড মার্জগুলির অনুমতি দেওয়া হয় ( --ff-onlyকমান্ড লাইন থেকে বিকল্প দেওয়ার সমতুল্য )।


ফাস্ট-ফরোয়ার্ড ডিফল্ট কারণ:

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

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

এই ক্ষেত্রে, আপনি কনফিগার ফাইল এই ধরণের সেট আপ শেষ করতে পারেন :

[branch "master"]
# This is the list of cmdline options that should be added to git-merge 
# when I merge commits into the master branch.

# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.

# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.

mergeoptions = --no-commit --no-ff

ওপি মন্তব্যগুলিতে যুক্ত করেছে:

আমি [স্বল্প-স্থায়ী] শাখাগুলির জন্য ফাস্ট-ফরোয়ার্ডে কিছুটা বোধগম্যতা দেখছি, তবে এটি ডিফল্ট ক্রিয়াকলাপ করার অর্থ হ'ল গিট আপনাকে ধরে নিয়েছে ... প্রায়শই [স্বল্পকালীন] শাখা থাকে। যুক্তিসঙ্গত?

জেফ্রমি উত্তর:

আমি মনে করি শাখাগুলির আজীবন ব্যবহারকারীর চেয়ে পৃথক পৃথক রয়েছে। অভিজ্ঞ ব্যবহারকারীদের মধ্যে যদিও সম্ভবত অনেক বেশি স্বল্প-স্থায়ী শাখা থাকার প্রবণতা রয়েছে।

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

আরও সাধারণভাবে আমি যুক্ত করি:

এটি সত্যই আপনার বিকাশের কর্মপ্রবাহের উপর নির্ভর করে :

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

"আপনি কখন শাখা করবেন? " দেখুন

আসলে, যখন তুমি Mercurial শাখা মডেল বিবেচনা, এটা তার অন্তঃস্থলে হয় এক সংগ্রহস্থলের প্রতি শাখা (যদিও আপনি তৈরি করতে পারেন বেনামী মাথা, বুকমার্ক এবং এমনকি নামে শাখা )
দেখুন "- তুলনা করুন এবং কনট্রাস্ট গীত এবং তত্পর"

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


বাহ যে দ্রুত ছিল। ;) আমি --no-ff বিকল্প সম্পর্কে জানি, তবে আমি আমার বৈশিষ্ট্যটি স্ক্রু করার পরে কেবল দ্রুত-ফরোয়ার্ড সম্পর্কে সন্ধান করব। আমি স্বল্প জীবন্ত শাখাগুলির জন্য ফাস্ট-ফরোয়ার্ডে কিছুটা বোধগম্যতা দেখছি, তবে এটি ডিফল্ট ক্রিয়াকলাপ করার অর্থ, গিটটি ধরে নিয়েছে যে আপনি প্রায়শই এইরকম সংক্ষিপ্ত জীবন্ত শাখা রাখেন। যুক্তিসঙ্গত?
ফ্লোরিয়ান পিলজ

@ ফ্লোরিয়ান: আমি বিশ্বাস করি এটি প্রক্রিয়াটির একটি যুক্তিসঙ্গত দৃষ্টিভঙ্গি। আমি একটি কনফিগারেশনের উদাহরণ যুক্ত করেছি যা আপনি মাস্টারগুলিতে মার্জ করার ব্যবস্থা করতে চান সেটআপ করবে।
ভোনসি

ধন্যবাদ, কনফিগারেশনের ফাইলটিকে এ জাতীয় গ্যাচচগুলি এড়াতে সহায়তা করা উচিত। :) শুধুমাত্র স্থানীয়ভাবে "গিট কনফিগারেশন শাখা.মাষ্টার.ডেম্পশনস '--no-ff'" দিয়ে এই কনফিগারেশনটি প্রয়োগ করেছেন
ফ্লোরিয়ান পিলজ

2
@ বেহরংসেইদজাদেহ: রিবাজিং অন্য একটি বিষয় (যা এই পৃষ্ঠায় আগে উল্লেখ করা হয়নি): যতক্ষণ না আপনি আপনার featureশাখাটিকে পাবলিক রেপোতে চাপান না , আপনি masterযতবার চান তার উপরে এটি পুনর্বার করতে পারবেন । দেখুন stackoverflow.com/questions/5250817/...
VonC

4
@ বেহরংসেইদজাদেহ: নিজেই একটি রিবেস কোনও ইতিহাস রৈখিক করবে না। এটি কীভাবে আপনি নিজের featureশাখার পরিবর্তনগুলিকে পুনরায় এতে একীভূত করলেন masterতা ইতিহাস রৈখিক করে তোলে কি না। একটি সাধারণ ফাস্ট-ফওয়ার্ড মার্জ এটিকে রৈখিক করে তুলবে। যদি আপনি দ্রুত-ফরওয়ার্ডের সংশ্লেষের আগে সেই featureশাখার ইতিহাস পরিষ্কার করে থাকেন, তবে স্ট্যাকওভারফ্লো / প্রশ্নগুলি / 25৪২৫৫৪৪/২ তে উল্লিখিত উল্লেখযোগ্য প্রতিশ্রুতি রেখে যদি তা বোঝা যায়
ভোনসি

42

আমাকে একটা উপর একটু প্রসারিত করা যাক VonC এর খুব ব্যাপক উত্তর :


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

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


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

আছে HTH


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

1
@ ডিওএক্সএক্সএক্স: হ্যাঁ, ব্যতিক্রমগুলি রয়েছে যেমন যেমন যেখানে একটি শাখা অন্যটিতে তৈরি হয় (হয় প্রত্যক্ষভাবে বা পূর্ববর্তীকে মাস্টার হিসাবে মার্জ করার পরে)।
জাকুব নরবস্কি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.