আমি কীভাবে গিটে একীভূত হওয়ার প্রাকদর্শন করতে পারি?

397

আমার একটি গিট শাখা রয়েছে (উদাহরণস্বরূপ মূল লাইন) এবং আমি অন্য একটি উন্নয়ন শাখায় মার্জ করতে চাই। বা আমি কি?

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

এখনও অবধি, আমি যে সেরাটির সাথে আসতে পারি তা হ'ল merge --no-ff --no-commitএবং তারপরে diff HEAD।

git git-merge

— Glenjamin
সূত্র

17

আমি ঠিক git mergeএবং git reset --keep HEAD@{1}যদি আমি ফলাফল পছন্দ না করি।

— জান হুডেক

3

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

— ক্যাসাবেল

2

আপনার আসল পদ্ধতিটি ঠিক তাই করে। আমার মন্তব্যের মূল বক্তব্যটি হ'ল পৃথক পৃথক পৃথকীকরণগুলি সন্ধান করা সমস্ত ভাল এবং ভাল, আপনার যদি একটি জটিল মার্জ থাকে তবে আপনি সমস্ত মার্জ কমিটগুলি স্বতন্ত্রভাবে ভাল হলেও অবাক করে দিতে পারেন।

— ক্যাসাবেল

2

@ জান: কিছু কারণে, সাহায্য git reset --keep HEAD@{1}ফিরিয়ে দিয়েছেন fatal: Cannot do a keep reset in the middle of a merge.?

— মোয়ে

3

--previewগিট-মার্জ করার বিকল্প নেই কেন ?

— গৌই

283

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

তবে, আপনি যদি নিশ্চিত করতে চান যে আপনি নিজের বর্তমান শাখাটি জগাখিচুড়ি করছেন না, বা আপনি দ্বন্দ্বের অস্তিত্ব নির্বিশেষে মার্জ করতে প্রস্তুত নন, কেবল একটি নতুন উপ-শাখা তৈরি করুন এবং এটি মার্জ করুন:

কৌশল 1: নিরাপদ উপায় - একটি অস্থায়ী শাখা বন্ধ করুন:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

দ্বন্দ্বগুলি কী তা যদি আপনি কেবল দেখতে চান তবে আপনি কেবল অস্থায়ী শাখাটি ফেলে দিতে পারেন। আপনাকে মার্জটিকে "বাতিল" করা বিরক্ত করার দরকার নেই এবং আপনি আপনার কাজে ফিরে যেতে পারেন - কেবল 'মাইব্র্যাঞ্চ' আবার চেকআউট করুন এবং আপনার শাখায় আপনার কোনও মার্জড কোড বা মার্জ সংঘাত থাকবে না।

এটি মূলত শুকনো রান run

কৌশল 2: আপনি স্পষ্টভাবে একত্রীকরণ করতে চাইলে তবে দ্বন্দ্ব না থাকলে কেবল

git checkout mybranch
git merge some-other-branch

যদি গিট বিবাদগুলির প্রতিবেদন করে (এবং কেবল যদি বিরোধগুলি হয় তবে) আপনি তা করতে পারেন:

git merge --abort

যদি মার্জটি সফল হয় তবে আপনি এটিকে বাতিল করতে পারবেন না (কেবল রিসেট করুন)।

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

[সম্পাদনা: ২০১--নভেম্বর - আমি কৌশলটি 2 এর জন্য 1 এ অদলবদল করেছিলাম, কারণ মনে হয় বেশিরভাগ লোক "নিরাপদ পথ" খুঁজছেন। কৌশল 2 এখন একটি নোটের আরও একটি বিষয় যে আপনি যদি কেবলমাত্র মার্জটি বিরোধিতা করে থাকেন যা আপনি মোকাবেলা করতে প্রস্তুত নন তবে আপনি কেবল মার্জটি বাতিল করতে পারেন। মন্তব্য পড়লে মনে রাখবেন!]

— Kasapo
সূত্র

2

কৌশলের জন্য +1 ২ অস্থায়ী শাখা যা মার্জ করার সময় ঠিক কী হবে তা দেখায়। কৌশল 1 হ'ল আমি এই বিশেষ ক্ষেত্রেটি এড়াতে চাই।

— গর্ডোলিও

2

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

— paxdiablo

6

আপনি git merge --no-ff --no-commitযদি সরাসরি পরিবর্তনগুলি করতে না চান তবে আপনি একটি করতে পারেন। এটি আলাদা শাখার "প্রয়োজন" কে মুছে ফেলে, পরিবর্তনগুলি পর্যালোচনা করা সামান্য কিছু সহজ করে তোলে, তবে o

— জেরার্ড ভ্যান হেলডেন

এবং যদি আপনি সিদ্ধান্ত নেন যে আপনি মোটেও মার্জ করতে চান না এবং আসলে আরও কিছু কোড লিখবেন এবং তারপরে আপনার শাখায় প্রতিশ্রুতিবদ্ধ করুন যাতে আপনি একটি পরীক্ষা সার্ভারে কেবল আপনার শাখাটি মোতায়েন করতে পারেন, তবে কি আপনাকে এখনও পুনরায় ফিরিয়ে আনতে হবে না git merge --no-ff --no-commit? আমার ধারণা আপনি এর পরেও কিছু করতে পারেন git merge --abortযদি আপনি যা দেখেন তাই পছন্দ করেন না? এমনকি সংযুক্তি দ্বন্দ্ব তৈরি করে না?

— কাসাপো

বেশিরভাগ লোক অনুলিপি এবং পেস্ট করতে পছন্দ করেন এবং খুব বেশি ভাবেন না। সুতরাং, কৌশল 1 এর জন্য, সম্ভবত অস্থায়ী স্থানীয় শাখায় মার্জটি বাতিল করতে git reset --hard HEADএবং তারপরে একটি পৃথক শাখা চেকআউট git checkout <different branch name>করে অস্থায়ী শাখাটি মোছার উপায়টিও যুক্ত করুন git delete -b <name of temporary branch>।

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

400

git log ..otherbranch
- বর্তমানের শাখায় মার্জ করা হবে এমন পরিবর্তনের তালিকা।
git diff ...otherbranch
- সাধারণ পূর্বপুরুষ (মার্জ বেস) থেকে কী একীভূত হবে তার মাথা থেকে আলাদা। দুটি বিন্দুর তুলনায় একটি বিশেষ অর্থ রয়েছে এমন তিনটি বিন্দু নোট করুন (নীচে দেখুন)।
gitk ...otherbranch
- শাখাগুলি গ্রাফিকাল উপস্থাপনা কারণ তারা গতবার মার্জ হয়েছিল।

খালি স্ট্রিং বোঝায় HEAD, তাই কেবল ..otherbranchপরিবর্তে HEAD..otherbranch।

দুটি বনাম তিনটি বিন্দুর পুনর্বিবেচনার তালিকা (লগ, গিটক ইত্যাদি) তালিকার চেয়ে পৃথক পৃথক অর্থ রয়েছে। লগ এবং অন্যদের জন্য দুটি বিন্দু ( a..b) অর্থ যা কিছু আছে bতবে নয় aএবং তিনটি বিন্দু ( a...b) এর অর্থ সমস্ত কিছু যা কেবলমাত্র এক aবা এর মধ্যে রয়েছে b। কিন্তু দুই পুনর্বিবেচনা এবং সেখানে সহজ ক্ষেত্রে দুটি বিন্দুর দ্বারা প্রতিনিধিত্ব (সঙ্গে পরিবর্তন কাজ a..b) থেকে সহজ পার্থক্য নেই aকরার bএবং তিনটি বিন্দু ( a...b) সাধারণ পূর্বপুরুষ এবং তাদের মধ্যে গড় পার্থক্য b( git diff $(git merge-base a b)..b)।

— জান হুডেক
সূত্র

7

তৃতীয় বিন্দুটি যে অংশটি আমি অনুপস্থিত ছিল তা ধন্যবাদ! লগ অ্যাপ্রোচটিও ভালভাবে কাজ করে, লগ

— পি

1

আমি এটি git checkout masterচেষ্টা করার আগে আমি নিখোঁজ ছিল । আমি ভাবছিলাম যে কেন এটি বলছে যে আমার সমস্ত পরিবর্তনগুলি অতিরিক্ত লিখিত হতে চলেছে ...

— Droogans

5

git show ..otherbranchবর্তমান পরিবর্তিত শাখায় একীভূত হবে এমন পরিবর্তনের এবং পার্থক্যের তালিকা প্রদর্শন করবে।

— গউই

4

এটি পুরোপুরি সঠিক নয়, বিশেষত চেরি বাছাইয়ের জন্য।

— void.pointer

2

@ অকার্যকর.পোয়েন্টার, গিট চেরি-পিকগুলি বিশেষভাবে সংযুক্তিতে বিশেষভাবে ব্যবহার করে না তাই এটি এখানেও হয় না so একটি মার্জ কৌশল লেখা যেতে পারে যা হতে পারে, তবে যতদূর আমি জানি, এটি কখনও ছিল না।

— জানু হুডেক

19

আপনি যদি আমার মতো হন তবে আপনি তার সমতুল্য সন্ধান করছেন svn update -n। নিম্নলিখিতটি কৌতুকটি করতে দেখা যাচ্ছে। নোট করুন যে কোনও git fetchপ্রথমটি নিশ্চিত করুন যাতে আপনার স্থানীয় রেপোতে তুলনা করার জন্য উপযুক্ত আপডেট থাকে।

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

অথবা আপনি যদি নিজের মাথা থেকে দূরবর্তী পর্যন্ত আলাদা করতে চান:

$ git fetch origin
$ git diff origin/master

আইএমও এই সমাধানটি শীর্ষ সমাধানের তুলনায় অনেক সহজ এবং কম ত্রুটিযুক্ত প্রবণ (এবং সেইজন্য আরও কম ঝুঁকিপূর্ণ) যা "মার্জ তার পরে বাতিল" প্রস্তাব দেয়।

— djschny
সূত্র

1

হওয়া উচিত $ git checkout target-branchএবং তারপরে $ git diff --name-status ...branch-to-be-merged(তিনটি বিন্দু প্রয়োজনীয় তাই তাদের টাইপ করুন)

— লু 55

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

— পিটারফ্লিন

সম্ভবত ২০১২ সালে জিনিসগুলি ভিন্ন ছিল, তবে এই দিনগুলিতে একীভূত হওয়া বাতিল করা বেশ নির্ভরযোগ্য বলে মনে হয়, তাই এখনই এটি "অনেক সহজ এবং কম ত্রুটির প্রবণ" হিসাবে চিহ্নিত করা ঠিক মনে করি না।

— ডেভিড জেড

8

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

আপনি masterযদি শাখায় মার্জ হয়ে developযান তবে সত্যিকার অর্থে শাখায় কী পরিবর্তন হবে তা দেখতে এখনই:

git merge-tree $(git merge-base master develop) master develop

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

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

- https://git.seveas.net/previewing-a- विसरा-result.html

(লিঙ্কটির জন্য ডেভিড নর্মিংটনকে ধন্যবাদ)

পুনশ্চ:

যদি আপনি মার্জ সংঘাত পেতে পারেন তবে এগুলি আউটপুটে সাধারণ দ্বন্দ্ব চিহ্নিতকারীদের সাথে দেখাবে, যেমন:

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

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

— hraban
সূত্র

1

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

— dreftymac

1

@dreftymac এই প্রভাবের জন্য কিছুই খুঁজে পাচ্ছে না। আপনি এর মতো কিছু ব্যবহার করতে পারেন git merge-tree ... | grep -q '^[a-z].*in both$' && echo conflict || echo safe to mergeতবে এটি সূক্ষ্ম; আমি সম্ভবত একটি কেস ভুলে যাচ্ছি। এর পরিবর্তে আপনি সংঘাতের চিহ্নিতকারীদের জন্য পরীক্ষা করতে চান? উদাহরণস্বরূপ, এটি "তাদের মুছে ফেলা হয়েছে, আমাদের পরিবর্তিত হয়েছে" শৈলীর দ্বন্দ্বগুলি ধরে না। (আমি ঠিক পরীক্ষা করেছি এবং এটি দ্বন্দ্বের চিহ্নগুলিও দেখায় না, সুতরাং এখানে নিরাপদ থাকতে আপনার একটি

— ক্ষুদ্রতর

1

less -Rআপনার কনফিগারেশনটি পরিবর্তন না করে রঙিন আউটপুট পরিচালনা করতে ব্যবহার করুন ।

— গিয়াকোমো আলজেটা

ধন্যবাদ জিয়াকোমো আলজিটা, আমি এটি আপডেট করেছি।

— hraban

6

আপনি যদি ইতিমধ্যে পরিবর্তনগুলি আনেন তবে আমার প্রিয়টি হ'ল:

git log ...@{u}

এর জন্য গিটটি দরকার 1.7.x যদিও আমি বিশ্বাস করি। @{u}স্বরলিপি মূল প্রজেক্টের শাখা জন্য একটি "সাধারণভাবে সংক্ষেপে" তাই এটা একটু চাইতে বেশী বহুমুখী git log ...origin/master।

দ্রষ্টব্য: আপনি যদি zsh এবং বর্ধিত গ্লোব জিনিসটি ব্যবহার করেন তবে আপনাকে সম্ভবত এর মতো কিছু করতে হবে:

git log ...@\{u\}

— পাবলো ওলমোস দে আগুইলেরা সি।
সূত্র

6

বিদ্যমান উত্তরগুলিতে যুক্ত করার পরে, একটি মার্জ হওয়ার পূর্বে ভিন্নতা এবং / অথবা লগ দেখানোর জন্য একটি উপাত্ত তৈরি করা যেতে পারে। একাধিক উত্তর fetchএকত্রীকরণের "প্রাকদর্শন" করার আগে প্রথমে করণীয় বাদ দেয় ; এটি এমন একটি উপাধি যা এই দুটি পদক্ষেপকে একের সাথে এক করে দেয় (পারদার্থের hg incoming/ / এর অনুরূপ কিছু অনুকরণ করে outgoing)

সুতরাং, " git log ..otherbranch" তৈরি করে আপনি নিম্নলিখিতগুলিতে এতে যুক্ত করতে পারেন ~/.gitconfig:

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

প্রতিসামগ্রীর জন্য, নিম্নলিখিত নামটি ধাক্কা দেওয়ার আগে, প্রতিশ্রুতিবদ্ধ প্রতিশ্রুতিবদ্ধ এবং কী ধাক্কা দেওয়া হবে তা দেখানোর জন্য ব্যবহার করা যেতে পারে:

    # what would be pushed (currently committed)
    outgoing = log @{u}..

এবং তারপরে আপনি সংক্ষিপ্তসার সারাংশের জন্য git incomingপ্রচুর পরিবর্তন git incoming -pদেখাতে " " বা " " " প্যাচ (অর্থাত্" ডিফ ")" git incoming --pretty=oneline"," git pull" চালাতে পারেন, আপনি তখন (allyচ্ছিকভাবে) চালাতে পারেন" " আসলে একীভূত। (যদিও, যেহেতু আপনি ইতিমধ্যে এনেছেন, একত্রীকরণটি সরাসরি করা যেতে পারে))

তেমনিভাবে, " git outgoing" আপনাকে চালাতে গেলে কি ধাক্কা দেওয়া হবে তা দেখায় " git push"।

— মাইকেল
সূত্র

3

git log currentbranch..otherbranchআপনি যদি মার্জ করেন তবে আপনাকে সেই কমিটগুলির তালিকা দেবে যা বর্তমান শাখায় যাবে। কমিট সম্পর্কে বিশদ দেয় যা লগ করার জন্য সাধারণ যুক্তিগুলি আপনাকে আরও তথ্য দেবে।

git diff currentbranch otherbranchদুটি চুক্তির মধ্যে পার্থক্য দেবে যা এক হয়ে যাবে। এটি একটি আলাদা হবে যা আপনাকে মার্জ হয়ে যাবে এমন সমস্ত কিছু দেয়।

এই সাহায্য করবে?

— নওফাল ইব্রাহিম
সূত্র

2

আসলে, ভুল। কারেন্টব্র্যাঞ্চে কমিটেরgit log otherbranch..currentbranch তালিকা দেয় । আপনি, বর্তমান ডগা করতে হতে-মার্জ সংস্করণ, সম্বন্ধে বেহুদা হিসাবে এটি হওয়া যায় যা থেকে বিবিধতা কারণ কি আপনি চান একত্রীকরণ মাথা থেকে একত্রীকরণ বেস থেকে পরিবর্তন দেয়। git diff otherbranch currentbranch

— জান হুডেক

ধন্যবাদ। আমি গাছের নাম পরিবর্তন করেছি।

— নওফাল ইব্রাহিম

3

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

— সরকারি কর্মচারী
সূত্র

2

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

এই বলে যে, এখানে একটি পদ্ধতি যা প্রান্তিকভাবে নিকটে আসে:

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

এটি কোন ন্যায্য ইঙ্গিত দেয় যে কোন কমিটগুলি এটিকে মার্জে পরিণত করবে। ভিন্নতা দেখতে, যুক্ত করুন -p। ফাইলের নাম দেখতে, কোন যোগ --raw, --stat, --name-only, --name-status।

git diff TARGET_BRANCH...SOURCE_BRANCHপদ্ধতির (জান হুডকের উত্তর দেখুন) সমস্যাটি হ'ল, যদি আপনার উত্স শাখায় ক্রস সংশ্লেষ থাকে তবে আপনি ইতিমধ্যে আপনার টার্গেট শাখায় পরিবর্তনগুলি দেখতে পাবেন see

— antak
সূত্র

1

সম্ভবত এটি আপনাকে সাহায্য করতে পারে? গিট-ডিফ-ট্রি - দুটি গাছের বস্তুর মাধ্যমে প্রাপ্ত ব্লবগুলির সামগ্রী এবং মোডের সাথে তুলনা করে

— Chugaister
সূত্র

1

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

এটি আমার কার্যকারিতা, যদি এটি অন্য কাউকে সাহায্য করে তবে:

এই দৃশ্যে আমার কাছে QA নামে একটি শাখা রয়েছে যা শেষ প্রযোজনার মুক্তির পর থেকে এর মধ্যে অনেক পরিবর্তন রয়েছে। আমাদের শেষ প্রযোজনা রিলিজটি "15.20.1" এর সাথে ট্যাগ করা আছে। আমার আরেকটি বিকাশ শাখা আছে যা নিউ_স্টফ বলে আমি কিউএ শাখায় মার্জ করতে চাই। QA এবং new_stuff উভয়ই 15.20.1 ট্যাগটিকে "অনুসরণ" করে (গিটক দ্বারা রিপোর্ট করা) প্রতিশ্রুতি দেয়।

git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_files

এই নির্দিষ্ট ফাইলগুলিকে আমি কেন লক্ষ্যবস্তু করতে আগ্রহী তা নিয়ে এখানে কিছু আলোচনা রয়েছে:

গিট একীভূত হওয়ার বিষয়ে আমি কীভাবে বিশ্বাস করব?

/software/199780/how-far-do-you-trust-automerge

— লরা
সূত্র