আপনি কখন গিট মার্জের পরিবর্তে গিট রিবেস ব্যবহার করবেন?

1544

গিট রিবেস বনাম গিট মার্জ কখন ব্যবহার করার পরামর্শ দেওয়া হয়?

একটি সফল রিবেস পরে আমার কি এখনও একীভূত হওয়া দরকার?

git  version-control  git-merge  git-rebase 
— Coocoo4Cocoa
সূত্র
2
— TStamper
16
— stackexchanger
6
যে লোকেরা রিবেস ব্যবহার করতে পছন্দ করে তাদের মধ্যে একটি সমস্যা হ'ল এটি নিয়মিত তাদের কোডটি চাপানো থেকে বিরত রাখে। সুতরাং পরিষ্কার ইতিহাস চাইলে তাদের কোড ভাগ করা থেকে বিরত থাকে, যা আমি মনে করি এটি আরও গুরুত্বপূর্ণ।
— স্ট্যাটিক_আরটি
9
@ স্ট্যাটিক_আরটি: এটি ঠিক সত্য নয়। আপনি যদি নিয়মিতভাবে আপনার পরিবর্তনগুলি ঠেকানো থেকে বিরত থাকেন তবে আপনি একটি রিবেস-ভিত্তিক প্রবাহকে ভুল ব্যবহার করছেন।
— জাজলিন
5
এটি সত্যই লজ্জার বিষয় যে অ্যান্ড্রু অরনটের উত্তর এবং পেসের উত্তর আগে পোস্ট করা হয়নি, কারণ তারা এই প্রশ্নের উত্তর আগের উত্তরগুলির চেয়ে আরও বিস্তৃতভাবে জবাব দিয়েছিল যা ইতিমধ্যে অনেক ভোট জমেছিল।
— মার্ক বুথ

উত্তর:

1134

সংক্ষিপ্ত সংস্করণ

  • মার্জ এক শাখায় সমস্ত পরিবর্তন নেয় এবং সেগুলি একটি প্রতিশ্রুতিতে অন্য শাখায় মার্জ করে।
  • রেবেস বলেছেন যে আমি যে বিন্দুতে একটি নতুন প্রারম্ভিক বিন্দুতে সরানোর জন্য ব্রাঞ্চ করেছি তা চাই

সুতরাং আপনি যখন কোন এক ব্যবহার করবেন?

একত্রিত করা

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

রি-বেসের ফলে

  • দ্বিতীয় পরিস্থিতিটি হ'ল যদি আপনি কিছু বিকাশ শুরু করেন এবং তার পরে অন্য বিকাশকারী কোনও সম্পর্কযুক্ত পরিবর্তন করেন। আপনি সম্ভবত টান এবং তারপর চান রি-বেসের ফলে সংগ্রহস্থল থেকে বর্তমান সংস্করণ থেকে আপনার পরিবর্তনগুলি বেস করতে।
— রব ডি মার্কো
সূত্র
105
@ রব মার্জ হওয়ার সময় অন্তর্বর্তীকালীন প্রতিশ্রুতি রক্ষণাবেক্ষণের কথা উল্লেখ করেছেন। আমি বিশ্বাস করি ডিফল্টরূপে শাখা বি (যে বৈশিষ্ট্য শাখাটির উপর আপনি কাজ করছেন) শাখা এম (মাস্টার শাখা) এম তে একটি প্রতিশ্রুতি তৈরি করবে যা বিটি দুটি বিভক্ত হওয়ার পরে হয়েছিল। তবে আপনি যদি - স্কোয়াশ বিকল্পটি ব্যবহার করে মার্জ করেন তবে শাখা বিতে করা সমস্ত কমিটগুলি "একসাথে লম্পড" হয়ে যাবে এবং শাখা এম তে একক প্রতিশ্রুতি হিসাবে মার্জ হয়ে যাবে, আপনার মাস্টার শাখায় লগটি সুন্দর এবং পরিষ্কার রাখবে। স্কোয়াশিং সম্ভবত আপনি যা চান আপনি যদি চান যদি আপনার বিকাশকারী অনেকগুলি স্বাধীনভাবে কাজ করে এবং আবার মাস্টার হিসাবে মার্জ হয়।
— spaaarky21
19
আমি বিশ্বাস করি মার্জ করার বিষয়ে @ spaary21 এর অনুমানটি সঠিক নয়। আপনি যদি একটি শাখা বি কে মাস্টার এম এর সাথে একীভূত করেন তবে এম এর উপর কেবলমাত্র একক প্রতিশ্রুতি থাকবে (বি এর একাধিক কমিট থাকলেও), আপনি প্লেইন বা - স্কোয়াশ মার্জটি ব্যবহার না করেই নির্বিশেষে। - স্কোয়াশ কী করবে তা হ'ল পিতামাতার হিসাবে বি'র রেফারেন্সটি মুছে ফেলা। একটি ভাল ভিজ্যুয়ালাইজেশন এখানে রয়েছে: syntevo.com/smartgithg/howtos.html?page=work
— ف
14
@ জাইপসকিন এটি আমি যা দেখছি তা নয়। আমি কেবল যাচাই করার জন্য একটি দ্রুত পরীক্ষা করেছি। একটি পাঠ্য ফাইল, initএকটি নতুন রেপো, addফাইল এবং সহ একটি ডিরেক্টরি তৈরি করুন commit। একটি নতুন বৈশিষ্ট্য শাখা চেকআউট করুন ( checkout -b feature।) পাঠ্য ফাইলটি পরিবর্তন করুন, প্রতিশ্রুতি দিন এবং পুনরাবৃত্তি করুন যাতে বৈশিষ্ট্য শাখায় দুটি নতুন কমিট থাকে। তারপর checkout masterএবং merge feature। ইন log, আমি মাস্টার সম্পর্কে আমার প্রাথমিক প্রতিশ্রুতি দেখি, তারপরে বৈশিষ্ট্য থেকে মার্জ করা দু'জনের পরে। আপনি যদি merge --squash featureবৈশিষ্ট্যটি মাস্টারের সাথে একীভূত হন তবে প্রতিশ্রুতিবদ্ধ না হন, তবে মাস্টার সম্পর্কে একমাত্র নতুন প্রতিশ্রুতিটি আপনি নিজেরাই বানাবেন।
— spaaarky21
21
@ spaarky21 দেখে মনে হচ্ছে আমরা দু'জনেই ঠিক আছি। যখন দ্রুত-ফরওয়ার্ড একীভূত হওয়া সম্ভব হয় (যেমন আপনার উদাহরণ হিসাবে), গিটটি ডিফল্ট হবে ফিচার শাখা বিতে সমস্ত কমিটগুলি অন্তর্ভুক্ত করার জন্য (বা আপনার পরামর্শ অনুসারে, আপনি একক প্রতিশ্রুতিতে একত্রিত করার জন্য - স্কোয়াশ ব্যবহার করতে পারেন)। তবে যে ক্ষেত্রে এম এবং বি দুটি বিভক্ত শাখা রয়েছে যা আপনি মার্জ করছেন, গিতে বি শাখা বি থেকে পৃথক পৃথক পৃথক পৃথকীকরণের সমস্তগুলিকে এমতে মিশ্রিত করা হবে না (যদি আপনি - স্কোয়াশ ব্যবহার করেন বা না করেন)।
— জ্যাপসকিন
6
কেন এই উত্তরটিতে এখনও "(আপনি অন্তর্বর্তীকালীন সমস্ত প্রতিশ্রুতি রক্ষা করার বিষয়ে চিন্তা করেন না)" কেন? '09-এ এটি কোনও অর্থবহ হয়নি এবং এটি এখন কোনও অর্থবোধ করে না। এছাড়াও, অবশ্যই আপনি কেবল তখনই পুনঃব্যবস্থা করতে চাইবেন যদি অন্য বিকাশকারী আপনার প্রয়োজনীয় প্রয়োজনীয় পরিবর্তনগুলি করে - যদি তারা সম্পর্কিত না করে পরিবর্তনগুলি করে, তবে আপনার বৈশিষ্ট্য শাখাটি কোনওভাবেই দ্বন্দ্ব ছাড়াই সহজেই মার্জ হওয়া উচিত, এবং আপনার ইতিহাসকে মূল নির্দেশ দেওয়া হবে।
— মার্ক বুথ
372

ইহা সাধারণ. পুনর্বাসনের সাথে আপনি অন্য একটি শাখাকে আপনার কাজের নতুন ভিত্তি হিসাবে ব্যবহার করার কথা বলেছেন ।

আপনার যদি, উদাহরণস্বরূপ, একটি শাখা থাকে তবে masterআপনি একটি নতুন বৈশিষ্ট্য বাস্তবায়নের জন্য একটি শাখা তৈরি করেন এবং বলেছিলেন যে আপনি এটির নাম cool-featureরেখেছেন অবশ্যই মাস্টার শাখাটি আপনার নতুন বৈশিষ্ট্যের ভিত্তি।

এখন একটি নির্দিষ্ট সময়ে আপনি masterশাখায় প্রয়োগ করা নতুন বৈশিষ্ট্যটি যুক্ত করতে চান । আপনি কেবল শাখায় স্যুইচ করতে masterএবং মার্জ করতে পারবেন cool-feature:

$ git checkout master
$ git merge cool-feature

তবে এইভাবে একটি নতুন ডামি কমিট যুক্ত করা হয়েছে। আপনি যদি স্প্যাগেটি-ইতিহাস এড়াতে চান তবে আপনি পুনঃব্যবস্থা করতে পারেন :

$ git checkout cool-feature
$ git rebase master

এবং তারপরে এটি মার্জ করুন master:

$ git checkout master
$ git merge cool-feature

এবার, যেহেতু টপিক শাখায় একই বৈশিষ্ট্যযুক্ত মাস্টার প্লাস নতুন বৈশিষ্ট্যটি নিয়ে কমিট রয়েছে, তাই মার্জটি কেবল দ্রুত-অগ্রসর হবে।

— আলডো 'xoen' গিয়ামেলুচা
সূত্র
31
but this way a new dummy commit is added, if you want to avoid spaghetti-history- এটা কেমন খারাপ?
— レ ッ ク ス
6
এছাড়াও, --no-ff সংযুক্তির পতাকাটি খুব দরকারী।
— অ্যালডো 'xoen' গিয়ামেলুকা
3
@ ア レ ッ ク user হিসাবে ব্যবহারকারী Sean Schofieldএকটি মন্তব্যে বলেছেন: "রিবেসটিও দুর্দান্ত কারণ আপনি একবারে আপনার জিনিসগুলি মাস্টারে ফিরিয়ে আনুন (যা ইতিমধ্যে বর্ণিত হিসাবে তুচ্ছ) আপনি এটি আপনার কমিটের ইতিহাসের" শীর্ষ "এ বসে আছেন On প্রকল্পগুলি যেখানে বৈশিষ্ট্যগুলি লিখিত হতে পারে তবে বেশ কয়েক সপ্তাহ পরে মার্জ হয়ে যায়, আপনি কেবল তাদেরকে মাস্টারের সাথে একীভূত করতে চান না কারণ তারা ইতিহাসে ফিরে আসার মাস্টার পথে "স্টাফড" হয়ে যায় I ব্যক্তিগতভাবে আমি গিট লগ করতে এবং দেখতে সক্ষম হতে পছন্দ করি সাম্প্রতিক বৈশিষ্ট্যটি ঠিক উপরে "শীর্ষে" রয়েছে। নোটের তারিখগুলি সংরক্ষণ করা আছে তা নোট করুন - রিবেস সেই তথ্য পরিবর্তন করে না ""
— অ্যাড্রিয়েন
4
মনে রাখবেন যে এই সব পদ (- আমি এটা এখানে পুনরায় বহন মনে merge, rebase, fast-forward, ইত্যাদি) একটি নির্দেশ acyclic গ্রাফ নির্দিষ্ট হেরফেরের উল্লেখ করা হয়। তারা সেই মানসিক মডেলটি মাথায় রেখেই তর্ক করতে সহজ হয়ে যায়।
— রায় টিঙ্কার
10
@ অ্যাল্ডোতে একটি পুনর্বাসিত ইতিহাস সম্পর্কে "পরিষ্কার" বা "পরিপাটি" কিছুই নেই। এটি সাধারণত নোংরা এবং আইএমএইচও ভয়ঙ্কর কারণ আসলে কী হয়েছে আপনার কোনও ধারণা নেই। "ক্লিনস্ট" গিট ইতিহাসটি আসলে ঘটেছে। :)
— মার্নেন লাইবো-কোসার
269

টিসম্পার দ্বারা উল্লিখিত আমার নিজের উত্তরটির পরিপূরক করতে ,

  • মার্জ করার আগে একটি রিবেস প্রায়শই করা ভাল ধারণা, কারণ ধারণাটি হ'ল আপনি আপনার শাখায় Yযে শাখার Bসংশ্লেষ করবেন সেটির কাজটি আপনি একীভূত করবেন।
    তবে আবার মার্জ করার আগে আপনি নিজের শাখায় যে কোনও দ্বন্দ্ব সমাধান করেছেন (যেমন: "রিবেস", যেমন "শাখার সাম্প্রতিক বিন্দু থেকে আমার শাখায় আমার কাজটি পুনরায় খেলুন B)
    সঠিকভাবে করা গেলে পরবর্তীকালে আপনার শাখা থেকে মার্জ করুন to শাখা Bদ্রুত এগিয়ে যেতে পারে।

  • একটি মার্জ সরাসরি গন্তব্য শাখাকে প্রভাবিত করে B, যার অর্থ মার্জগুলি আরও ভাল তুচ্ছ হতে পারে, অন্যথায় Ba শাখাটি স্থিতিশীল অবস্থায় ফিরে আসতে দীর্ঘতর হতে পারে (আপনার সমস্ত দ্বন্দ্বের সমাধানের সময়)

একটি রিবেস পরে মার্জ পয়েন্ট?

আমি যে বর্ণনা করছি সে ক্ষেত্রে আমি Bআমার শাখায় পুনর্বার আছি, কেবল আমার কাজটি সাম্প্রতিক বিন্দু থেকে রিপ্লে করার সুযোগ পাবে B, তবে আমার শাখায় থাকা অবস্থায়।
এই ক্ষেত্রে, আমার "পুনরায় খেলানো" কাজটি আনার জন্য এখনও একত্রীকরণের প্রয়োজন B।

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

ডিফল্ট একটি গিট ট্রি যখন আমরা সংহত বা পুনরায় ব্যবস্থা না করি

rebase1

আমরা মুক্তি দিয়ে পেয়েছি:

rebase3

এই দ্বিতীয় দৃশ্যটি প্রায়: আমি কীভাবে নতুন বৈশিষ্ট্যটি মাস্টারে ফিরে পাব।

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

তাই:

  • "পুনর্নির্মাণ বনাম মার্জ" কে একটি কাজ আমদানির দুটি উপায় হিসাবে দেখা যেতে পারে, বলুন master,।
  • তবে "রিবাজে তারপরে মার্জ করুন" প্রথমে বিচ্ছিন্নতার বিরোধের সমাধানের জন্য একটি বৈধ কর্মপ্রবাহ হতে পারে, তারপরে আপনার কাজটি ফিরিয়ে আনুন।
— VonC
সূত্র
17
পুনর্বাসনের পরে সংযুক্তি দ্বন্দ্বগুলি সমাধান না করেই একটি তুচ্ছ দ্রুত এগিয়ে।
— ওপেকলপ
4
@ ওবেলক্যাপ: প্রকৃতপক্ষে, এই ধারণাটি এক ধরণের: আপনি আপনার পরিবেশের সমস্ত সমস্যা-সংঘাত গ্রহণ করেন (আপনার নতুন বৈশিষ্ট্য শাখার অভ্যন্তরে রিবায়েস মাস্টার) এবং তারপরে সহকারী, নতুন বৈশিষ্ট্যটি মার্জ করুন: 1 পিকো-সেকেন্ড (দ্রুত- ফরোয়ার্ড) যদি মাস্টারটির কোনও বিবর্তন না থাকে
— ভোনসি
27
রিবেসটিও দুর্দান্ত কারণ আপনি অবশেষে আপনার জিনিসগুলি আবার মাস্টারে মার্জ করে ফেলেন (যা ইতিমধ্যে বর্ণিত হিসাবে তুচ্ছ) আপনি এটি আপনার প্রতিশ্রুতিবদ্ধ ইতিহাসের শীর্ষে বসে আছেন। বড় প্রকল্পগুলিতে যেখানে বৈশিষ্ট্যগুলি লিখিত হতে পারে তবে বেশ কয়েক সপ্তাহ পরে মার্জ হয়ে যায়, আপনি কেবল তাদেরকে মাস্টারে মার্জ করতে চান না কারণ তারা ইতিহাসে ফিরে আসার মাস্টার পথে "স্টাফড" হয়ে যায়। ব্যক্তিগতভাবে আমি গিট লগ করতে সক্ষম হতে এবং সাম্প্রতিক বৈশিষ্ট্যটি "শীর্ষে" দেখতে দেখতে চাই। কমিটের তারিখগুলি সংরক্ষিত আছে তা নোট করুন - পুনর্বাসনা সেই তথ্য পরিবর্তন করে না।
— শান শোফিল্ড
3
@ জো: মানসিকভাবে, আপনি বলছেন যে "আমার যে কোনও পরিবর্তন (আমার প্রাইভেট শাখায় বিচ্ছিন্নভাবে করা হয়েছে) অন্য শাখার শীর্ষে পুনরায় খেলুন, তবে পুনরায় ব্যবস্থা নেওয়ার পরে আমাকে আমার ব্যক্তিগত শাখায় ছেড়ে দিন"। স্থানীয় ইতিহাস সাফ করার জন্য এটি একটি ভাল সুযোগ, "চেকপয়েন্টটি কমিট করে", ভাঙ্গা দ্বিখণ্ডিত এবং ভুল দোষের ফলাফলগুলি এড়িয়ে চলে। "গিট ওয়ার্কফ্লো" দেখুন: Sandofsky.com/blog/git-workflow.html
— ভোনসি
4
@ স্কোয়ারস্কোয়ার কীটি হল আপনার স্থানীয় পরিবর্তনগুলি সর্বশেষতম প্রবাহ শাখার শীর্ষে কীভাবে সামঞ্জস্যপূর্ণ তা দেখা । যদি আপনার কোনও অঙ্গীকার দ্বন্দ্বের পরিচয় দেয়, আপনি এখনই তা দেখতে পাবেন। একটি মার্জ শুধুমাত্র একটি (মার্জড) প্রতিশ্রুতি প্রবর্তন করে, যা আপনার নিজের স্থানীয় কমিটমেন্টের মধ্যে কোনটি দ্বন্দ্বকে যুক্ত করে, তা দেখার সহজ উপায় ছাড়াই অনেক সংঘাতের সূত্রপাত হতে পারে। সুতরাং একটি ক্লিনার ইতিহাস ছাড়াও, আপনি পরিবর্তনের আরও ভালো ভিউ আপনি পরিচয় করিয়ে দ্বারা কমিট (রি-বেসের ফলে গুলোতে), কারণ যে উল্টোদিকে কমিট সব পরিবর্তন মূল প্রজেক্টের শাখা চালু (এক একক একত্রীকরণ মধ্যে ডাম্প)।
— ভোনসি
229

টি এল; ডিআর

আপনার যদি সন্দেহ থাকে তবে মার্জটি ব্যবহার করুন।

সংক্ষিপ্ত উত্তর

একটি রিবেস এবং একীকরণের মধ্যে কেবলমাত্র পার্থক্যগুলি হ'ল:

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

সুতরাং সংক্ষিপ্ত উত্তরটি হ'ল রিবেস বাছাই করা বা আপনি নিজের ইতিহাসটি কেমন দেখতে চান তার উপর ভিত্তি করে মার্জ করা ।

দীর্ঘ উত্তর

কোন অপারেশনটি ব্যবহার করবেন তা বেছে নেওয়ার ক্ষেত্রে কয়েকটি কারণ বিবেচনা করা উচিত।

আপনি যে শাখাটি আপনার দলের বাইরে অন্য বিকাশকারীদের সাথে ভাগ করে নেওয়া থেকে পরিবর্তনগুলি পাচ্ছেন (যেমন ওপেন সোর্স, পাবলিক)?

যদি তাই হয় তবে রিবেস করবেন না। রিবেস শাখাটি নষ্ট করে দেয় এবং সেইগুলি বিকাশকারীরা ব্যবহার না করে ভাঙা / অসামঞ্জস্যপূর্ণ সংগ্রহস্থল রাখবে git pull --rebase। অন্যান্য বিকাশকারীদের দ্রুত বিরক্ত করার এটি একটি ভাল উপায়।

আপনার উন্নয়ন দল কতটা দক্ষ?

রিবেস একটি ধ্বংসাত্মক অপারেশন। এর অর্থ, আপনি যদি এটি সঠিকভাবে প্রয়োগ না করেন তবে আপনি প্রতিশ্রুতিবদ্ধ কাজটি হারাতে পারেন এবং / অথবা অন্যান্য বিকাশকারীর সংগ্রহস্থলগুলির ধারাবাহিকতা ভঙ্গ করতে পারেন।

আমি এমন দলগুলিতে কাজ করেছি যেখানে বিকাশকারীরা এমন এক সময় থেকে এসেছিলেন যখন সংস্থাগুলি শাখা এবং মার্জিংয়ের সাথে ডিল করার জন্য নিবেদিত কর্মীদের সামর্থ্য করতে পারে। এই বিকাশকারীরা গিট সম্পর্কে খুব বেশি জানেন না এবং বেশি কিছু জানতে চান না। এই দলগুলিতে আমি কোনও কারণে ছাড় দেওয়ার সুপারিশ করার ঝুঁকি নেব না।

শাখা নিজেই দরকারী তথ্য উপস্থাপন করে

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

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

আপনি কোনও কারণে মার্জটি ফিরিয়ে দিতে চান?

একত্রিতকরণকে ফিরিয়ে আনার তুলনায় পুনরায় ফিরিয়ে দেওয়া (পূর্বাবস্থায় ফেরা হিসাবে) একটি রিবেস যথেষ্ট কঠিন এবং / অথবা অসম্ভব (যদি রিবেসে দ্বন্দ্ব ছিল)। যদি আপনি মনে করেন যে কোনও সুযোগ আছে তবে আপনি ফিরে যেতে চান তবে মার্জটি ব্যবহার করুন।

আপনি কি একটি দলে কাজ করেন? যদি তা হয়, তবে আপনি কি এই শাখায় কোনও কিছু বা কোনও কিছুই গ্রহণ করতে ইচ্ছুক?

রিবেস ক্রিয়াকলাপগুলিকে একটি সংশ্লিষ্ট সাথে টানতে হবে git pull --rebase। আপনি যদি নিজেরাই কাজ করে থাকেন তবে আপনি উপযুক্ত সময়ে কোনটি ব্যবহার করা উচিত তা আপনি মনে করতে সক্ষম হতে পারেন। আপনি যদি একটি দলে কাজ করছেন তবে এটি সমন্বয় করা খুব কঠিন হবে। এ কারণেই বেশিরভাগ রিবেস ওয়ার্কফ্লোগুলি সমস্ত মার্জ (এবং git pull --rebaseসমস্ত টানার জন্য) রিবেস ব্যবহার করার পরামর্শ দেয় ।

সাধারণ কল্পকাহিনী

মার্জ ইতিহাস ধ্বংস করে (স্কোয়াশগুলি কমিট করে)

ধরে নিচ্ছি আপনার নিম্নলিখিত সংশ্লেষ রয়েছে:

    B -- C
   /      \
  A--------D

কিছু লোক জানিয়েছেন যে মার্জটি কমিটের ইতিহাসকে "ধ্বংস" করে দেয় কারণ আপনি যদি কেবলমাত্র মাস্টার শাখার (এ - ডি) লগটি দেখতে চান তবে আপনি বি এবং সিতে থাকা গুরুত্বপূর্ণ প্রতিশ্রুতি বার্তাগুলি মিস করবেন would

যদি এটি সত্য হয় তবে আমাদের মতো প্রশ্ন থাকবে না । মূলত, আপনি বি এবং সি দেখতে পাবেন যতক্ষণ না আপনি স্পষ্টভাবে সেগুলি না দেখার জন্য জিজ্ঞাসা করেন (- প্রথম-পিতামাতার ব্যবহার করে)। এটি নিজের জন্য চেষ্টা করা খুব সহজ।

রিবেস নিরাপদ / সহজ সংহতকরণের অনুমতি দেয়

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

রিবেস শীতল / যৌনতর / আরও পেশাদার

আপনি যদি "সময় বাঁচাতে" উপনামটি পছন্দ করেন তবে আপনার জন্য পুনর্বাসনাটি rmহতে rm -rfপারে।

আমার দুই সেন্ট

আমি সবসময় ভাবি যে কোনও দিন আমি এমন একটি দৃশ্য দেখতে পাব যেখানে গিট রিবেস হ'ল দুর্দান্ত সরঞ্জাম যা সমস্যার সমাধান করে। অনেকটা আমি মনে করি আমি এমন একটি দৃশ্যের মুখোমুখি হব যেখানে গিট রিফ্লগ একটি দুর্দান্ত সরঞ্জাম যা আমার সমস্যা সমাধান করে। আমি গিটির সাথে এখন পাঁচ বছরেরও বেশি সময় ধরে কাজ করেছি। এটা হয়নি।

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

আপডেট (4/2017)

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

— গতি
সূত্র
5
বৈধতাযুক্ত উত্তর হওয়া উচিত।
— মিক 378
এটি অবশ্যই সেরা উত্তর। বিশেষত সর্বশেষ আপডেটে স্পষ্ট মন্তব্য সঙ্গে। এটি গিট ইতিহাসকে পরিষ্কার ও পরিষ্কার রাখতে সহায়তা করে তবে এটি নিরাপদে ব্যবহার করুন।
— zquintana
5
আমি বেশিরভাগই এই উত্তরটি পছন্দ করি। তবে: রিবেস কোনও "পরিষ্কার" ইতিহাস তৈরি করে না। এটি আরও রৈখিক ইতিহাস তৈরি করে, তবে এটি মোটেও একই জিনিস নয়, যেহেতু এখন প্রতিশ্রুতিবদ্ধ যে কতগুলি "ময়লা" লুকিয়ে আছে কে জানে? সবচেয়ে পরিষ্কার, ক্লিয়ার গিট ইতিহাস হ'ল যা শাখা রাখে এবং সততা বজায় রাখে।
— মার্নেন লাইবো-কোসার
3
"প্রচলিত কল্পকাহিনী, আপনি বি এবং সি প্রতিশ্রুতিবদ্ধ দেখতে পান": অগত্যা নয় !! আপনি কেবলমাত্র বি এবং সি দেখতে পাবেন যদি মার্জটি দ্রুত-ফরওয়ার্ড একীভূত হত এবং এটি কেবল তখনই সম্ভব, যদি কোনও বিরোধ না থাকে। যদি কোন্দল হয়, আপনি একক প্রতিশ্রুতি পান! তবে: আপনি প্রথমে মাস্টারটিকে বৈশিষ্ট্যটিতে মার্জ করতে পারেন এবং সেখানে দ্বন্দ্বগুলি সমাধান করতে পারেন এবং যদি আপনি বৈশিষ্ট্যটি মাস্টারে মার্জ করেন তবে আপনি বি এবং সি থেকে কমিট করবেন এবং আপনার ইতিহাসের মাস্টার থেকে (প্রথম) মার্জ থেকে একক কমিট এক্স পাবেন।
— জেরেমি বেনস
খুব ভাল ব্যাখ্যা! এটি আরও upvated করা আবশ্যক!
— ডিমেট করে
185

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

মার্জ করা আপনার প্রতিশ্রুতিগুলি বিলুপ্ত করে না । মার্জ ইতিহাস সংরক্ষণ করে! (কেবল গিটকে দেখুন) রিবেস ইতিহাস পুনর্লিখন করে, যা আপনি এটি ঠেলে দেওয়ার পরে একটি খারাপ বিষয় ।

মার্জ ব্যবহার করুন - যখনই আপনি ইতিমধ্যে ঠেলাঠেলি করেছেন তখন পুনরায় ব্যবহার করবেন না ।

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

অথবা আপনি নীচে একই ধারণার নিজস্ব সংস্করণ পড়তে পারেন।

মাস্টারের উপর একটি শাখা ছাড়:

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

বিপরীতে, একটি বিষয় শাখাকে মাস্টারে মার্জ করা:

  • এটিকে বর্তমান বজায় রাখতে সহায়তার জন্য মাস্টার থেকে টপিক শাখায় যে কোনও মার্জ সহ টপিক শাখাগুলি কোথায় তৈরি করা হয়েছে তার ইতিহাস সংরক্ষণ করে। বিকাশকারীরা যখন তৈরি করছিলেন তখন তারা কী কোড নিয়ে কাজ করছিল সে সম্পর্কে আপনি সত্যই ধারণা পেতে পারেন।
  • মাস্টার হ'ল একটি শাখা যা বেশিরভাগ সংশ্লেষের সমন্বয়ে গঠিত এবং এই মার্জ কমিটগুলির প্রত্যেকটি সাধারণত ইতিহাসের 'ভাল পয়েন্ট' যা যাচাই করা নিরাপদ, কারণ এখানেই বিষয় শাখা সংহত করার জন্য প্রস্তুত ছিল।
  • বিষয় শাখার সমস্ত স্বতন্ত্র কমিটগুলি সংরক্ষণ করা হয়, এগুলি সহ যে তারা কোনও বিষয় শাখায় ছিল, তাই সেই পরিবর্তনগুলি পৃথকীকরণ স্বাভাবিক এবং আপনি যেখানে প্রয়োজন সেখানে ড্রিল করতে পারেন।
  • মার্জ বিরোধগুলি কেবল একবার সমাধান করতে হবে (মার্জ হওয়ার পরে), সুতরাং বিষয় শাখায় অন্তর্বর্তী কমিট পরিবর্তনগুলি স্বাধীনভাবে সমাধান করতে হবে না।
  • মসৃণভাবে একাধিকবার করা যায়। আপনি যদি আপনার বিষয় শাখাকে পর্যায়ক্রমে মাস্টার হিসাবে সংহত করে থাকেন তবে লোকেরা বিষয় শাখায় বিল্ডিং চালিয়ে যেতে পারে এবং এটি স্বাধীনভাবে সংহত হতে পারে।
— অ্যান্ড্রু আরনট
সূত্র
3
এছাড়াও, গিট মার্জটিতে "--no-ff" (কোনও দ্রুত-ফরোয়ার্ড) বিকল্প নেই যা আপনাকে নির্দিষ্ট মার্জ দ্বারা প্রবর্তিত সমস্ত পরিবর্তনগুলি খুব সহজেই ফিরিয়ে আনতে দেয়।
— টিয়াগো
3
কেবল তি এটি আরও পরিষ্কার করে: আপনি 'আপনি যখনই ইতিমধ্যে ধাক্কা দিয়েছেন' পরিস্থিতিটি উল্লেখ করেছেন - এটি সাহসী হওয়া উচিত। লিনাস পোস্টের লিঙ্কটি দুর্দান্ত, বিটিডাব্লু।
— Honzajde
2
তবে মাস্টার থেকে আপনার বিষয় শাখায় "আপডেট" করা কি সেরা অনুশীলন নয়, আপনি পিআর এর মাধ্যমে বিষয় শাখাকে মাস্টার হিসাবে মার্জ করার আগে (আপনার শাখায় দ্বন্দ্ব সমাধান করার জন্য, মাস্টার নয়)? আমরা এটির মতোই করছি তাই বেশিরভাগ বিষয় শাখাগুলির একটি সর্বশেষ কমিট হিসাবে "শাখা মাস্টারকে টপিক -..." তে মিশ্রিত করা হয়েছে তবে এখানে এটিকে প্রত্যাবর্তনের "বৈশিষ্ট্য" হিসাবে তালিকাভুক্ত করা হয়েছে এবং কেউই এটি মার্জ করার জন্য উল্লেখ করে না ...?
— সমস্যাগুলি
2
@ অ্যান্ড্রুআরনট "বেশিরভাগ বিষয় শাখাগুলি তাদের লক্ষ্যবস্তুগুলিতে দ্বন্দ্ব ছাড়াই মার্জ করতে সক্ষম হওয়া উচিত" যখন 20 টি দেব 30 টি শাখায় কাজ করছেন তখন কীভাবে এটি সম্ভব হবে? আপনি নিজের উপর কাজ করার সময় মার্জ হবে - অবশ্যই অবশ্যই আপনাকে PR তৈরির আগে লক্ষ্য থেকে আপনার বিষয় শাখাটি আপডেট করতে হবে ... না?
— সমস্যাগুলি
3
সাধারণত, @ সুমিত না। উভয় শাখায় বা উভয় শাখায় পরিবর্তন আনা সত্ত্বেও গিট উভয় দিককে একত্রে সূক্ষ্মভাবে মার্জ করতে পারে। যখন দুটি শাখায় একই লাইন কোডের (বা খুব নিকটবর্তী) সংশোধন করা হবে তখনই আপনি বিবাদ পাবেন। যদি কোনও দলে এটি ঘন ঘন ঘটে থাকে তবে দলটিকে পুনর্বিবেচনা করতে হবে যে তারা দ্বন্দ্বের সমাধান করা একটি ট্যাক্স হওয়ায় তারা কীভাবে কাজটি বিতরণ করে এবং সেগুলি ধীর করে দেয়।
— অ্যান্ড্রু আর্নট
76

টিএলডিআর: এটি সবচেয়ে গুরুত্বপূর্ণ কিসের উপর নির্ভর করে - একটি পরিপাটি ইতিহাস বা উন্নয়নের ক্রমের সত্য উপস্থাপনা

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

যদি ক্রমের সত্য উপস্থাপনা সবচেয়ে গুরুত্বপূর্ণ হয় তবে আপনি ছাড় ছাড়াই একত্রীকরণ করবেন।

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

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

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

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

আর একবার আপনি রিবেস করতে চাইতে পারেন যখন আপনি যখন প্রবাহের দিকে ধাক্কা দেওয়ার আগে আপনার শাখা থেকে কমিটস থেকে মুক্তি পেতে চান। উদাহরণস্বরূপ: যে কমিটগুলি প্রাথমিকভাবে কিছু ডিবাগিং কোড প্রবর্তন করে এবং সেই কোডটি পরিষ্কার করে তা সম্পর্কে আরও কমিট করে। এটি করার একমাত্র উপায় একটি ইন্টারেক্টিভ রিবেস সম্পাদন করা:git rebase -i <branch/commit/tag>

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

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

আপডেট 3: Does one still need to merge after a successful rebase?হ্যাঁ, আপনি না। কারণটি হ'ল প্রত্যাবর্তন মূলত কমিটস "শিফটিং" এর সাথে জড়িত। যেমনটি আমি আগেই বলেছি, এই কমিটগুলি গণনা করা হয়, তবে যদি শাখা প্রশাখার দিক থেকে আপনার 14 টি কমিট থাকে তবে ধরে নেওয়া আপনার রিবেসে কোনও ভুল হয় না, আপনি 14 কমিট এগিয়ে যাবেন (আপনি যে পয়েন্টে প্রত্যাবর্তন করছেন) এর পরে রিবেস করা হয়েছে। পুনঃবাসের আগে আপনার একটি শাখা ছিল। আপনার পরে একই দৈর্ঘ্যের একটি শাখা থাকবে। আপনার পরিবর্তনগুলি প্রকাশের আগে আপনাকে এখনও মার্জ করতে হবে। অন্য কথায়, আপনি যতবার চান রিবেস করুন (আবার, কেবলমাত্র আপনি যদি আপনার পরিবর্তনগুলিকে প্রবাহিত না করেন)। আপনি পুনঃস্থাপনের পরেই মার্জ করুন।

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

যদিও সংযুক্তি পরিবর্তনগুলি সংহত করার অবশ্যই সহজতম এবং সর্বাধিক সাধারণ উপায়, তবে এটি একমাত্র নয়: রিবেস সংহতকরণের একটি বিকল্প উপায়।

সামান্য উন্নত মার্জ বোঝা

গিট যখন মার্জ করে, এটি তিনটি কমিটের সন্ধান করে:

  • (1) সাধারণ পূর্বপুরুষ প্রতিশ্রুতিবদ্ধ। আপনি যদি কোনও প্রকল্পে দুটি শাখার ইতিহাস অনুসরণ করেন তবে সর্বদা তাদের কমপক্ষে একটি কমিট সমান থাকে: সময়ে এই সময়ে, উভয় শাখায় একই বিষয়বস্তু ছিল এবং পরে আলাদাভাবে বিবর্তিত হয়েছিল।
  • (২) + (৩) প্রতিটি শাখার সমাপ্তি একীকরণের লক্ষ্য হ'ল দুটি শাখার বর্তমান অবস্থা একত্রিত করা। অতএব, তাদের নিজ নিজ সর্বশেষ সংশোধনীগুলি বিশেষ আগ্রহী। এই তিনটি কমিটকে একত্রিত করার ফলে আমরা যে ইন্টিগ্রেশনটির লক্ষ্য রেখেছি তার ফলস্বরূপ।

ফাস্ট-ফরওয়ার্ড বা মার্জ কমিট

খুব সাধারণ ক্ষেত্রে, ব্রাঞ্চিংয়ের পরে দুটি শাখার মধ্যে একটিরও নতুন কমিট নেই - এর সর্বশেষ প্রতিশ্রুতি এখনও সাধারণ পূর্বপুরুষ।

এখানে চিত্র বিবরণ লিখুন

এক্ষেত্রে, সংহতকরণ সম্পাদন করা মরিয়া: গিট সাধারণ পিতৃপুরুষদের প্রতিশ্রুতিবদ্ধতার শীর্ষে অন্য শাখার সমস্ত কমিট যুক্ত করতে পারে। গিট-এ, সংহতকরণের এই সর্বাধিকতম রূপকে "ফাস্ট-ফরোয়ার্ড" একীকরণ বলা হয়। উভয় শাখাই ঠিক একই ইতিহাস ভাগ করে।

এখানে চিত্র বিবরণ লিখুন

অনেক ক্ষেত্রে তবে উভয় শাখা পৃথকভাবে এগিয়ে গেছে।

এখানে চিত্র বিবরণ লিখুন

ইন্টিগ্রেশন করার জন্য, গিটকে একটি নতুন কমিট তৈরি করতে হবে যাতে তাদের মধ্যে পার্থক্য রয়েছে - মার্জ কমিট।

এখানে চিত্র বিবরণ লিখুন

হিউম্যান কমিটস এবং মার্জ কমিটস

সাধারণত, একটি প্রতিশ্রুতি যত্ন সহকারে একটি মানুষ তৈরি করে। এটি একটি অর্থবহ ইউনিট যা কেবলমাত্র সম্পর্কিত পরিবর্তনগুলিকে আবৃত করে এবং তাদের একটি মন্তব্য দিয়ে টিকা দেয়।

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

রিবেসের সাথে একীকরণ করা হচ্ছে

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

এখানে চিত্র বিবরণ লিখুন

আসুন ধাপে ধাপে একটি রিবেস অপারেশন দিয়ে চলুন। পূর্ববর্তী উদাহরণগুলির মতো দৃশ্যটি একই রকম: আমরা শাখা-বি থেকে পরিবর্তনগুলি শাখা-এতে সংহত করতে চাই, তবে এখন পুনরায় ব্যবহারের মাধ্যমে।

এখানে চিত্র বিবরণ লিখুন

আমরা এটি তিনটি পদক্ষেপে করব

  1. git rebase branch-A // Synchronises the history with branch-A
  2. git checkout branch-A // Change the current branch to branch-A
  3. git merge branch-B // Merge/take the changes from branch-B to branch-A

প্রথমে, গিট শাখা-এ-তে সমস্ত প্রতিশ্রুতি "পূর্বাবস্থায় ফিরিয়ে দেবে" যা লাইনগুলি শাখা শুরু করার পরে ঘটেছিল (সাধারণ পূর্বপুরুষের অঙ্গীকারের পরে)। তবে অবশ্যই এটি তাদের ত্যাগ করবে না: পরিবর্তে আপনি সেইসব অঙ্গীকারকে "সাময়িকভাবে রক্ষা পেয়েছেন" বলে ভাবতে পারেন।

এখানে চিত্র বিবরণ লিখুন

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

এখানে চিত্র বিবরণ লিখুন

চূড়ান্ত পদক্ষেপে, শাখা-এ-তে নতুন কমিটিগুলি পুনরায় প্রয়োগ করা হয় - তবে একটি নতুন অবস্থানে, শাখা-বি থেকে সংহত কমিটগুলির শীর্ষে (সেগুলি পুনরায় ভিত্তিক)।

ফলাফল দেখে মনে হচ্ছে উন্নয়নটি সরলরেখায় ঘটেছিল। সমস্ত সংযুক্ত পরিবর্তনগুলি সমন্বিত একত্রিত প্রতিশ্রুতির পরিবর্তে মূল কমিট কাঠামোটি সংরক্ষণ করা হয়েছিল।

এখানে চিত্র বিবরণ লিখুন

অবশেষে, আপনি কোনও অযাচিত এবং স্বয়ংক্রিয় উত্পন্ন কমিট ছাড়াই একটি পরিষ্কার শাখা শাখা- এ পাবেন।

দ্রষ্টব্য: দ্বারা দুর্দান্ত পোস্টটি নেওয়া হয়েছে git-tower। অসুবিধেও এর rebaseএকটি ভাল একই পোস্টে পড়া হয়।

— আবদুল্লাহ খান
সূত্র
খুব শীতল চিত্রের জন্য +1। আমি সবসময় চেয়েছিলাম যে গিট ফ্লো উদাহরণটি একইভাবে কোনও ভাগ্য ছাড়াই চিত্রিত করতে সক্ষম হব।
— মিকায়েল আবদুললেভ
60

মার্জ / রিবেস করার আগে:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

পরে git merge master:

A <- B <- C
^         ^
 \         \
  D <- E <- F

পরে git rebase master:

A <- B <- C <- D' <- E'

(এ, বি, সি, ডি, ই এবং এফ কমিট হয়)

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

— guybrush
সূত্র
30

এই বাক্যটি এটি পায়:

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

উত্স: 3.6 গিট ব্রাঞ্চিং - রিবেসিং, রিবেস বনাম মার্জ

— জোয়াকুইন সারজিওতো
সূত্র
25

এই উত্তরটি গিট ফ্লোকে কেন্দ্র করে ব্যাপকভাবে কেন্দ্রিক । টেবিল চমৎকার দিয়ে তৈরি করা হয়েছে হওয়া ASCII ছক জেনারেটর , এবং এই বিস্ময়কর কমান্ড (সঙ্গে ইতিহাস গাছ ওরফে যেমন git lg):

git log --graph --abbrev-commit --decorate --date=format:'%Y-%m-%d %H:%M:%S' --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%ad%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'

ইতিহাসের গাছগুলির সাথে আরও সুসংগত হওয়ার জন্য টেবিলগুলি বিপরীত কালানুক্রমিক ক্রমে থাকে। প্রথম git mergeএবং git merge --no-ffপ্রথমটির মধ্যে পার্থক্যটিও দেখুন (আপনি সাধারণত git merge --no-ffএটি ব্যবহার করতে চান কারণ এটি আপনার ইতিহাসকে বাস্তবের নিকটবর্তী করে তোলে):

git merge

আদেশগুলি:

Time          Branch "develop"             Branch "features/foo"
------- ------------------------------ -------------------------------
15:04   git merge features/foo
15:03                                  git commit -m "Third commit"
15:02                                  git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

* 142a74a - YYYY-MM-DD 15:03:00 (XX minutes ago) (HEAD -> develop, features/foo)
|           Third commit - Christophe
* 00d848c - YYYY-MM-DD 15:02:00 (XX minutes ago)
|           Second commit - Christophe
* 298e9c5 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git merge --no-ff

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"
------- -------------------------------- -------------------------------
15:04   git merge --no-ff features/foo
15:03                                    git commit -m "Third commit"
15:02                                    git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   1140d8c - YYYY-MM-DD 15:04:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/foo' - Christophe
| * 69f4a7a - YYYY-MM-DD 15:03:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 2973183 - YYYY-MM-DD 15:02:00 (XX minutes ago)
|/            Second commit - Christophe
* c173472 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git merge বনাম git rebase

প্রথম পয়েন্ট: বৈশিষ্ট্যগুলি বিকাশে সর্বদা মার্জ করুন, বৈশিষ্ট্যগুলি থেকে কখনই বিকাশ পুনরায় করুন । এটি রিব্যাসিংয়ের সুবর্ণ নিয়মের একটি পরিণতি :

এর সুবর্ণ নিয়ম git rebaseহ'ল এটি কখনই সর্বজনীন শাখায় ব্যবহার না করা ।

অন্য কথায় :

আপনি কোথাও ঠেলে দেওয়া কোনও জিনিসকে কখনই রিবাজ করবেন না।

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

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

বৈশিষ্ট্য শাখার মধ্যে

git merge

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- --------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   c0a3b89 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 37e933e - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   eb5e657 - YYYY-MM-DD 15:07:00 (XX minutes ago)
| |\            Merge branch 'features/foo' into features/bar - Christophe
| * | 2e4086f - YYYY-MM-DD 15:06:00 (XX minutes ago)
| | |           Fifth commit - Christophe
| * | 31e3a60 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| | |           Fourth commit - Christophe
* | |   98b439f - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \ \            Merge branch 'features/foo' - Christophe
| |/ /
|/| /
| |/
| * 6579c9c - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 3f41d96 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* 14edc68 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git rebase features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   7a99663 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 708347a - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 949ae73 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 108b4c7 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   189de99 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
| * 26835a0 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * a61dd08 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* ae6f5fc - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

থেকে developএকটি বৈশিষ্ট্য শাখায়

git merge

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m "Sixth commit"
15:08                                                                    git merge --no-ff develop
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   9e6311a - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 3ce9128 - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   d0cd244 - YYYY-MM-DD 15:08:00 (XX minutes ago)
| |\            Merge branch 'develop' into features/bar - Christophe
| |/
|/|
* |   5bd5f70 - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| * | 4ef3853 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| | |           Third commit - Christophe
| * | 3227253 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/ /            Second commit - Christophe
| * b5543a2 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 5e84b79 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/            Fourth commit - Christophe
* 2da6d8d - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m "Sixth commit"
15:08                                                                    git rebase develop
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   b0f6752 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 621ad5b - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 9cb1a16 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * b8ddd19 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/            Fourth commit - Christophe
*   856433e - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\            Merge branch 'features/foo' - Christophe
| * 694ac81 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 5fd94d3 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* d01d589 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

পার্শ্ব নোট

git cherry-pick

যখন আপনার কেবল একটি নির্দিষ্ট প্রতিশ্রুতি প্রয়োজন, git cherry-pickএটি একটি দুর্দান্ত সমাধান ( -xবিকল্পটি একটি লাইন সংযোজন করে যা " (চেরিটি কমিট থেকে নেওয়া ...) " মূল কমিট বার্তার মূল অংশে যুক্ত করে, তাই এটি সাধারণত এটি ব্যবহার করা ভাল - git log <commit_sha1>দেখুন এটা):

আদেশগুলি:

Time           Branch "develop"              Branch "features/foo"                Branch "features/bar"
------- -------------------------------- ------------------------------- -----------------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git cherry-pick -x <second_commit_sha1>
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

ফলাফল:

*   50839cd - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 0cda99f - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * f7d6c47 - YYYY-MM-DD 15:03:00 (XX minutes ago)
| |           Second commit - Christophe
| * dd7d05a - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * d0d759b - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   1a397c5 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
|/|
| * 0600a72 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * f4c127a - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/            Second commit - Christophe
* 0cf894c - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git pull --rebase

আমি নিশ্চিত না যে আমি ডেরেক গুরলেয়ের চেয়ে এটি আরও ভালভাবে ব্যাখ্যা করতে পারি ... মূলত এর git pull --rebaseপরিবর্তে ব্যবহার করুন git pull:) নিবন্ধটিতে যা অনুপস্থিত রয়েছে তা হ'ল আপনি এটি ডিফল্টরূপে সক্ষম করতে পারবেন :

git config --global pull.rebase true

git rerere

আবার, সুন্দরভাবে এখানে ব্যাখ্যা । তবে সোজা কথায়, যদি আপনি এটি সক্ষম করে থাকেন তবে আপনাকে আর একাধিক বার একই দ্বন্দ্বের সমাধান করতে হবে না।

— sp00m
সূত্র
15

প্রো গীত বই সত্যিই একটি ভাল ব্যাখ্যা রয়েছে rebasing পৃষ্ঠা ।

মূলত মার্জ দুটি করে কমিট করে একত্রিত হবে।

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

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

একা একা আমি প্রায় একচেটিয়াভাবে মার্জ করি। আমার শাখাগুলির 99% সময় এতটা পৃথক হয় না, তাই যদি বিবাদ হয় তবে এটি কেবল এক বা দুটি জায়গায়।

— xero
সূত্র
1
মার্জগুলি কমিটগুলি একত্রিত করে না - এটি ইতিহাসের পুনর্লিখন হবে। রিবেস তা করে।
— কেলিফজে
4

ইতিহাস ক্লিনার এবং ভান্ডার কাঠামোর লিনিয়ার লিনিয়ারে শাখা পাথ তৈরি করতে গিট রিবেস ব্যবহার করা হয়।

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

রিবেস করার পরে আমরা একটি অতিরিক্ত প্রতিশ্রুতি থেকে মুক্তি পেতে পারি যা আমরা দেখতাম যে আমরা একটি সাধারণ মার্জ করি কিনা।

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

— cvibha
সূত্র
4

আপনি যদি কেবলমাত্র একজন বিকাশকারী হন তবে সুস্পষ্ট ইতিহাসের জন্য আপনি মার্জ করার পরিবর্তে রিবেস ব্যবহার করতে পারেন

এখানে চিত্র বর্ণনা লিখুন

— yoAlex5
সূত্র
3

কিছু বাস্তব উদাহরণ, কিছুটা বড় আকারের বিকাশের সাথে যুক্ত যেখানে জেরিট পর্যালোচনা এবং বিতরণ সংহতকরণের জন্য ব্যবহৃত হয়:

আমি যখন আমার বৈশিষ্ট্য শাখাটিকে নতুন কোন দূরবর্তী মাস্টারে উন্নীত করি তখন আমি মার্জ করি। এটি ন্যূনতম উত্সাহের কাজ দেয় এবং বৈশিষ্ট্য বিকাশের ইতিহাস অনুসরণ করা সহজ উদাহরণস্বরূপ গিটকে ।

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

আমি যখন ডেলিভারি কমিট প্রস্তুত করি তখন আমি মার্জ হয়ে যাই।

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

আমার বিতরণ প্রতিশ্রুতিবদ্ধ কারণে যে কোনও কারণেই ইন্টিগ্রেশন ব্যর্থ হলে আমি পুনঃব্যবস্থা করি এবং আমি তা নতুন রিমোট মাস্টারের দিকে আপডেট করতে হবে।

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master
— মার্টিন জি
সূত্র
3

কি রিবেস এবং কোনটি মার্জ হয় তা বহুবার ব্যাখ্যা করা হয়েছিল, তবে কখন কী ব্যবহার করা উচিত?

আপনার কখন পুনরায় ব্যবহার করা উচিত?

  • আপনি যখন শাখাটি ঠেলেছেন না / অন্য কেউ এতে কাজ করছে না
  • আপনি পুরো ইতিহাস চান
  • আপনি সমস্ত স্বয়ংক্রিয়ভাবে উত্পাদিত "মার্জ .." প্রতিশ্রুতিবদ্ধ বার্তা এড়াতে চান

যেমন গিট রিবেস ইতিহাস পরিবর্তন করে। সুতরাং অন্য কেউ একই শাখায় / যখন আপনি এটি ঠেলাঠেলি করে কাজ করছেন তখন আপনার এটি ব্যবহার করা উচিত নয়। তবে আপনার যদি স্থানীয় একটি শাখা থাকে তবে আপনি একটি ক্লিনার ইতিহাস বজায় রাখতে আপনার শাখাটিকে মাস্টারে ফেরত দেওয়ার আগে মার্জ রিবেস মাস্টার করতে পারেন। এটি করার পরে, মাস্টার শাখায় মার্জ হওয়ার পরে এটি দৃশ্যমান হবে না যে আপনি মাস্টার শাখায় একটি শাখা ব্যবহার করেছেন - ইতিহাসটি "পরিষ্কার" কারণ আপনার স্বয়ংক্রিয়ভাবে উত্পন্ন "মার্জড .." নেই, তবে এখনও রয়েছে স্বয়ংক্রিয়ভাবে "সংহত .." না করেই আপনার মাস্টার শাখায় সম্পূর্ণ ইতিহাস comm

তবে নিশ্চিত হয়ে নিন যে আপনি git merge feature-branch --ff-onlyনিজের বৈশিষ্ট্যটি মূলদিকে ফিরে যাওয়ার সময় কোনও একক প্রতিশ্রুতি তৈরির কোনও দ্বন্দ্ব নেই তা নিশ্চিত করার জন্য ব্যবহার করেন use এটি আকর্ষণীয় যদি আপনি বৈশিষ্ট্য শাখার ইতিহাস পাওয়ার সাথে সাথে কাজ করেন এমন প্রতিটি কাজের জন্য বৈশিষ্ট্য শাখা ব্যবহার করছেন তবে "মার্জড .." অঙ্গীকার নয়

দ্বিতীয় দৃশ্যটি হ'ল, যদি আপনি কোনও শাখা থেকে শাখা করেন এবং প্রধান শাখায় কী পরিবর্তন হয়েছে তা জানতে চান। রেবেস আপনাকে তথ্য দেয় কারণ এতে প্রতিটি একক প্রতিশ্রুতি অন্তর্ভুক্ত থাকে।

আপনি কখন মার্জ ব্যবহার করবেন?

  • আপনি যখন শাখাটি ঠেলেছেন / অন্যরাও এতে কাজ করছে
  • আপনার পুরো ইতিহাসের দরকার নেই
  • কেবল মার্জ করা আপনার পক্ষে যথেষ্ট ভাল

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

— জেরেমি বেনস
সূত্র
-4

আমি কখন ব্যবহার করব git rebase? প্রায় কখনও না, কারণ এটি ইতিহাস পুনর্লিখন করে। git mergeপ্রায় সবসময়ই পছন্দনীয় পছন্দ, কারণ এটি আপনার প্রকল্পে যা ঘটেছিল তা সম্মান করে।

— মার্নেন লাইবো-কোসার
সূত্র
1
@ বেঞ্জামিনহুল ধন্যবাদ! -আমি আশা করি আমার উত্তরটি সত্য ভিত্তিক। এই ধরণের বিষয়ে আইএমএইচও-র মতামতের খুব কম জায়গা রয়েছে: এটি এমন একটি সত্য যে আপনার প্রকৃত ইতিহাস হারিয়ে যাওয়ার পরে জীবন আরও কঠিন হয়ে যায়।
— মার্নেন লাইবো-কোসার
1
একমত। মার্জ কখনই দুর্নীতিগ্রস্থ ইতিহাস ইত্যাদির দিকে পরিচালিত করবে না (যখন আপনি আপনার
— ধাক্কায়িত
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.