"গিট মার্জ -আস আওয়ারস" এর একটি "তাদের" সংস্করণ আছে কি?

Question

টপিক শাখা "বি" কে "এ" ব্যবহার করে মার্জ করার সময় git mergeআমি কিছু বিবাদ পেতে পারি। আমি জানি সমস্ত বিবাদগুলি "বি" সংস্করণ ব্যবহার করে সমাধান করা যেতে পারে।

আমি সচেতন git merge -s ours। তবে আমি যা চাই তা হ'ল কিছুটা git merge -s theirs।

কেন এটির অস্তিত্ব নেই? বিদ্যমান gitকমান্ডগুলির সাথে বিরোধী সংযুক্তির পরে আমি কীভাবে একই ফলাফল অর্জন করতে পারি ? ( git checkoutবি থেকে প্রতিটি নিমজ্জিত ফাইল)

আপডেট: কেবল শাখা এ থেকে কিছু বাদ দেওয়ার "সমাধান" (গাছের বি সংস্করণে মার্জ কমিট পয়েন্ট) নয় যা আমি খুঁজছি is

Comments

এই উত্তরটিও দেখুন: স্ট্যাকওভারফ্লো / প্রশ্নগুলি / ৯২৮৪66/২ - এটি এ এর ​​পরিবর্তে বি সংস্করণ বি ব্যবহারের উদাহরণটি পরিবর্তন করা তুচ্ছ

— রবি বাসাক

সমস্ত সম্ভাব্য উপায় সিমুলেট করার জন্য একটি শাখাকে অন্যের মতো তৈরি করার জন্য এসও উত্তর গিট কমান্ডটি দেখুন । git merge -s their

— ভনসি

সুতরাং আপনি সত্যিকার অর্থে কোনও git merge -s theirs(যা git merge -s oursএকটি অস্থায়ী শাখার সাহায্যে সহজেই অর্জন করা যায় ) সন্ধান করছেন না, যেহেতু -আমাদের শাখা থেকে মার্জ হওয়া পরিবর্তনের পরিবর্তনগুলি সম্পূর্ণ উপেক্ষা করা হচ্ছে ...

— নিকো মার্টিনি

@Torek - গীত devs না সত্যিই এটি খুঁজে যে প্রদান আক্রমণাত্মক theirsছাড়াও ours??? এটি উচ্চ স্তরের ইঞ্জিনিয়ারিং এবং গিটে ডিজাইন সমস্যার অন্যতম লক্ষণ: অসঙ্গতি।

— jwww

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

— থোমাজমৌরা

Answer 1

যোগ -Xকরার বিকল্প theirs। উদাহরণ স্বরূপ:

git checkout branchA
git merge -X theirs branchB

সবকিছু কাঙ্ক্ষিত উপায়ে একীভূত হবে।

কেবলমাত্র আমি সমস্যার কারণ দেখলাম তা হ'ল যদি শাখাবি থেকে ফাইলগুলি মুছে ফেলা হয়। গিট বাদে অন্য কিছু অপসারণ করলে তারা বিরোধ হিসাবে দেখা দেয়।

ফিক্স সহজ। git rmমুছে ফেলা সমস্ত ফাইলের নাম দিয়ে চালান :

git rm {DELETED-FILE-NAME}

এরপরে, -X theirsপ্রত্যাশা অনুযায়ী কাজ করা উচিত।

অবশ্যই, git rmকমান্ডটি দিয়ে প্রকৃত অপসারণ করা দ্বন্দ্বকে প্রথমে সংঘটিত হতে বাধা দেবে।

---

দ্রষ্টব্য : একটি দীর্ঘ ফর্ম বিকল্প উপস্থিত রয়েছে।

এটি ব্যবহার করতে, প্রতিস্থাপন করুন:

-X theirs

সঙ্গে:

--strategy-option=theirs

Comments

মূল প্রশ্নের আরও ভাল সমাধানের জন্য নীচে অন্যান্য উত্তর দেখুন (পল প্লেডিজ)।

— ম্যালকম

এটি "মার্জ কৌশল theirs" এর মতো নয় বলে মনে করা দরকার। -একটি হ'ল পুনরাবৃত্ত কৌশলটি প্রয়োগ করা কৌশল বিকল্প । এর অর্থ হ'ল পুনরাবৃত্ত কৌশলটি এখনও যা কিছু করতে পারে তা মার্জ করবে এবং দ্বন্দ্বের ক্ষেত্রে কেবল "তাদের" যুক্তিতে ফিরে আসবে। যদিও উপরের মতো বেশিরভাগ ক্ষেত্রে এটির প্রয়োজন হয়, এটি "শাখা বি থেকে সমস্ত কিছু যেমন নেওয়া হয়" তেমন নয়। এটি পরিবর্তে যাইহোক প্রকৃত মার্জটি করে।

— তৈমুর

এটি অন্যান্য কমান্ডগুলির সাথেও কাজ করে। আমি কেবল একটি 'গিট চেরি-পিক শে 1-এক্স তাদের' করেছি। ধন্যবাদ!

— ম্যাক্স হোহেনেগার

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

— ইভান ক্র্যাভিয়কভ

@ ব্যবহারকারী 3338098: হ্যাঁ, আপনি ঠিক বলেছেন। আমি প্রশ্নটি আবার পড়ি, এবং এটিও এতটা ভাল নয়। দুর্ভাগ্যক্রমে, বিভ্রান্তির মূল কারণটি উত্তর নয় এমনকি এমনকি প্রশ্নও নয়। মার্জ লেখকের একই নামটি 'আমাদের' দেওয়া এবং মার্জ কৌশলটির বিকল্প 'পুনরাবৃত্ত' বিকল্পটি দেওয়া গিট লেখকদের নকশা পছন্দ। এই ক্ষেত্রে বিভ্রান্তি কার্যত অনিবার্য।

— ইভান ক্র্যাভিয়াকভ

Answer 2

আমাদের চেক-আউট শাখাতে শাখাটি মার্জ করার একটি সম্ভাব্য এবং পরীক্ষিত সমাধান:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

এটিকে স্বয়ংক্রিয় করার জন্য আপনি এটিকে যুক্তি হিসাবে ব্রাঞ্চএ এবং ব্রাঞ্চবি ব্যবহার করে স্ক্রিপ্টে মুড়িয়ে রাখতে পারেন।

আপনি যেমনটি আশা করবেন ঠিক তেমনই এই সমাধানটি মার্জ কমিটের প্রথম এবং দ্বিতীয় পিতামাতার সংরক্ষণ করে git merge -s theirs branchB।

Comments

প্রশ্ন: আপনার শাখাটিএমইপি দরকার কেন? তুমি কি ঠিক পারছো না git reset --soft branchA?

— cdunn2001

@ সিডুএন ২০০১: একরকম আমি একই জিনিস ভেবেছিলাম, তবে নেই। নোট করুন যে git reset --hardপরিবর্তিত যা branchAপয়েন্ট প্রতিশ্রুতিবদ্ধ ।

— Tsuyoshi Ito

একটি বোকা প্রশ্ন জিজ্ঞাসা করার জন্য দুঃখিত কিন্তু কেন এই পদ্ধতি তৃতীয় ভাল? সুবিধাগুলি / অসুবিধাগুলি কী

— chrispepper1989

@ chrispepper1989 -x এগুলি কেবল দ্বন্দ্বগুলিকেই প্রভাবিত করে , যদি আমাদের কোনও কুঁচি পরিষ্কারভাবে প্রয়োগ করা যায় তবে এটি ফলাফলের সংশ্লেষের মধ্য দিয়ে যাবে। এই ক্ষেত্রে, শেষ কমান্ডের মতো দেখানো হয়েছে, আমরা সংঘাত পেয়ে যাচ্ছি যা ব্রাঞ্চবির সাথে পুরোপুরি সাদৃশ্যপূর্ণ , দ্বন্দ্ব ছিল কিনা তা নির্বিশেষে।

— আঙ্কেলজিভ 16

@ উঙ্কলেজেইভ এই ব্যাখ্যার জন্য আপনাকে ধন্যবাদ, সুতরাং মূলত "তাদের" করার ফলে দ্বি-বিরোধী পরিবর্তন এবং ফাইলগুলি অন্তর্নিহিত কোডের মতো হবে না যা টানা কোডের মতো নয়।

— chrispepper1989

Answer 3

গিটের পুরানো সংস্করণ আপনাকে "তাদের" একত্রিত করার কৌশলটি ব্যবহার করার অনুমতি দিয়েছে:

git pull --strategy=theirs remote_branch

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

git fetch origin
git reset --hard origin

যদিও সতর্ক থাকুন যে এটি প্রকৃত সংশ্লেষের চেয়ে আলাদা। আপনার সমাধান সম্ভবত সেই বিকল্প যা আপনি সত্যই সন্ধান করছেন।

Comments

আমি জুনিয়ো হামানো ব্যাখ্যাটি মোটেই বুঝতে পারি না। কীভাবে git reset --hard originতাদের শৈলীর একত্রীকরণের সমাধান? আমি যদি ব্রাঞ্চবিকে ব্রাঞ্চএতে যুক্ত করতে চাই (যেমন অ্যালান ডাব্লু স্মিথের উত্তরে), আমি কীভাবে resetপদ্ধতিটি ব্যবহার করে করব ?

— জেমস ম্যাকমাহন

@ জেমস ম্যাকমাহন: জুনিও সি হামানো পয়েন্টটি git reset --hard"তাদের" স্টাইলের একীকরণ নয় । অবশ্যই, git reset --hardকোনও বিষয়ে মার্জ কমিট বা কোনও কমিট তৈরি করে না। তাঁর বক্তব্যটি হ'ল হেডে যা কিছু আছে তার পরিবর্তে আমাদের একত্রীকরণ ব্যবহার করা উচিত নয় । যদিও আমি অগত্যা একমত হই না।

— Tsuyoshi Ito

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

— ফিলিপ ওকলে

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

— szeitlin

আমি সত্যিই দর্শন বুঝতে পারি না। আমি কেবল ব্যবহার করেছি theirsকারণ আমি ঘটনাক্রমে দুটি পৃথক শাখায় কিছু ফাইল পরিবর্তন করেছি এবং প্রতিটি ফাইলের জন্য ম্যানুয়ালি না করে একটির পরিবর্তনগুলি বাতিল করতে চেয়েছিলাম।

— সুডো

Answer 4

আপনার পছন্দসই ফলাফল কী তা সম্পূর্ণরূপে পরিষ্কার নয়, সুতরাং উত্তর এবং তাদের মন্তব্যে এটি করার "সঠিক" উপায় সম্পর্কে কিছুটা বিভ্রান্তি রয়েছে। আমি একটি ওভারভিউ দেওয়ার চেষ্টা করি এবং নিম্নলিখিত তিনটি বিকল্প দেখতে পারি:

সংঘাতের জন্য মার্জ এবং বি ব্যবহার করে দেখুন

এই না "জন্য তাহাদেরই সংস্করণ git merge -s oursকিন্তু" "এর জন্য তাহাদেরই সংস্করণ git merge -X ours" (যার জন্য ছোট git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

উদাহরণস্বরূপ অ্যালান ডাব্লু স্মিথের উত্তর এটি করে।

কেবল বি থেকে সামগ্রী ব্যবহার করুন

এই সৃষ্টি মার্জ উভয় শাখার জন্য কমিট কিন্তু থেকে সমস্ত পরিবর্তন বাতিল branchAএবং একমাত্র সামগ্রী রাখে branchB।

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

মনে রাখবেন যে মার্জটি এখন প্রথম পিতামাতার সাথে চুক্তি করে তা হ'ল branchBকেবলমাত্র দ্বিতীয়টি এসেছে branchA। উদাহরণস্বরূপ, গ্যান্ডালফ 458 এর উত্তর এটি করে।

কেবল বি থেকে সামগ্রী ব্যবহার করুন এবং সঠিক পিতামাতার ক্রম রাখুন

এটি আসল "এর জন্য তাদের সংস্করণ git merge -s ours"। এটিতে বিকল্পটির মতো একই বিষয়বস্তু রয়েছে (যেমন কেবলমাত্র এটি থেকে branchB) তবে পিতামাতার ক্রমটি সঠিক, অর্থাত প্রথম পিতা-মাতার কাছ থেকে আসে branchAএবং দ্বিতীয়টি আসে branchB।

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

এই কি পল Pladijs এর উত্তর (ক অস্থায়ী শাখা প্রয়োজন ছাড়া) করে।

Comments

বিকল্প 3 এর একটি ক্লিনার সংস্করণ:git checkout branchA; git merge -s ours --no-commit branchB; git read-tree -um @ branchB; git commit

— 18'22

@ জেথিল: আপনার সংস্করণটি আরও সংক্ষিপ্ত হলেও এটি নিম্ন স্তরের ("নদীর গভীরতানির্ণয়") কমান্ডও ব্যবহার read-treeকরে যা গড় গিট ব্যবহারকারী সম্ভবত ব্যবহার করতে পারে না (কমপক্ষে আমি নই ;-))। উত্তরের সমাধানগুলি কেবল উচ্চ স্তরের ("চীনামাটির বাসন") ব্যবহার করে বেশিরভাগ গিট ব্যবহারকারীদের জানা উচিত। আমি তাদের পছন্দ করি তবে তবুও আপনার সংস্করণটির জন্য আপনাকে ধন্যবাদ!

— সিয়েগি

আপনি দ্বিতীয় থেকে শেষ ধাপটি ব্যাখ্যা করতে পারেন (চেকআউট ব্রাঞ্চএ)? মনে হচ্ছে এটি থাকা উচিত নয়।

— প্যাট্রিক

@ পেট্রিক, এই পদক্ষেপটি প্রয়োজনীয়। আপনি যদি এটিকে এড়িয়ে যান তবে আপনি একই প্রতিশ্রুতি পাবেন তবে এই অঙ্গীকারের দিকে নির্দেশ করে আপনার কোনও শাখা থাকবে না। সুতরাং আপনি অন্য কোন প্রতিশ্রুতি / শাখায় স্যুইচ করার সাথে সাথে আপনি শেষ কমান্ড ( …commit --amend…) দিয়ে যে প্রতিশ্রুতিটি করেছিলেন তা "হারিয়ে যাবে"। আমি তাদের উত্তর দেওয়ার সাথে সাথে এই উত্তরে কিছু গ্রাফিকাল ব্যাখ্যা যুক্ত করার পরিকল্পনা করছি… ;-)

— সিগি

Answer 5

আমি এখন থেকে পল প্লেডিজের উত্তরটি ব্যবহার করেছি। আমি খুঁজে পেয়েছি, আপনি একটি "সাধারণ" মার্জ করতে পারেন, সংঘাত দেখা দেয়, তাই আপনিও করেন

git checkout --theirs <file>

অন্যান্য শাখা থেকে সংশোধন ব্যবহার করে দ্বন্দ্ব সমাধানের জন্য। আপনি যদি প্রতিটি ফাইলের জন্য এটি করেন, আপনার কাছ থেকে যেমন প্রত্যাশা করা হবে তেমন আচরণ করুন

git merge <branch> -s theirs

যাইহোক, চেষ্টাটি মেশানো-কৌশলটির সাথে তার চেয়ে বেশি হবে! (এটি গিট সংস্করণ 1.8.0 দিয়ে পরীক্ষা করা হয়েছিল)

Comments

ফাইলগুলির তালিকা পুনরুদ্ধার করা সম্ভব হলে দুর্দান্ত হবে। উদাহরণস্বরূপ, git ls-files --modified | xargs git addআমি উভয় পক্ষের

— সংযুক্তির

আসলে গিট উভয় পক্ষের ফাইলগুলিতে অ্যাড যুক্ত করে দেয় যার সাথে git ls-files --modifiedআমার ধারণা এটি এটিও একটি কার্যকর সমাধান solution

— andho

এটি যোগ করার জন্য ধন্যবাদ। তবে প্রায়শই এটি ফাইল-বাই-ফাইল বেসে প্রয়োজন হয় না। এছাড়াও, গিট স্ট্যাটাসটি একেবারে নীচে "নিমজ্জিত পাথগুলি" দেখায়। অমীমাংসিত পাথের তালিকা পেতে, আমি এই উপনামটি ব্যবহার করি:git config --global alias.unresolved '!git status --short|egrep "^([DAU])\1"'

— মেলভিন

এর অর্থ কি -Xএবং কি পার্থক্য -Xএবং -s? কোনও দলিল খুঁজে পাচ্ছে না।

— লেই ইয়াং

Answer 6

আমি আমার সমস্যাটি ব্যবহার করে সমাধান করেছি

git checkout -m old
git checkout -b new B
git merge -s ours old

Comments

"পুরাতন" শাখা থেকে "বি" একটি শাখা

— শে

Answer 7

গিফটি মার্জ করে "এ" তে টপিক শাখা "বি" মার্জ করার সময় আমি কিছু বিবাদ পেতে পারি। আমি> জানি সমস্ত বিবাদগুলি "বি" এর সংস্করণ ব্যবহার করে সমাধান করা যেতে পারে।

আমি আমাদের গিট সংশ্লেষ সম্পর্কে সচেতন am তবে আমি যা চাই তা হ'ল গিট একীভূত করার মতো> তাদের।

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

আপনি যা করতে চান তা ঠিক করুন, প্রথমে একটি শাখাকে অন্যটিতে মিশিয়ে দিন। আমি সবেমাত্র এটি করেছি এবং এটি দুর্দান্ত কাজ করেছে।

git checkout Branch
git merge master -s ours

তারপরে, চেকআউট মাস্টার করুন এবং এতে আপনার শাখাটি মার্জ করুন (এটি এখন সুচারুভাবে চলবে):

git checkout master
git merge Branch

Comments

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

— স্ট্যাকহোলা

এটি দুর্দান্ত কাজ করেছে, আপনাকে ধন্যবাদ।

— কোডি গ্রান্থাম

Answer 8

আপনি যদি শাখা A তে থাকেন তবে করুন:

git merge -s recursive -X theirs B

গিট সংস্করণ 1.7.8 এ পরীক্ষিত

Answer 9

সত্যিই সঠিকভাবে মার্জ করতে যা আপনি যে শাখায় মার্জ করছেন তা কেবলমাত্র ইনপুট নেয়

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

আমি জানি যে কোনও দৃশ্যে কোনও বিবাদ হবে না, আপনাকে অতিরিক্ত শাখা তৈরি করতে হবে না এবং এটি একটি সাধারণ মার্জ কমিটের মতো কাজ করে।

এটি সাবমডিউলগুলির সাথে দুর্দান্ত খেলছে না।

Comments

-আর এখানে কী করে?

— পি। মায়ার নোর

এইভাবে আপনি "সরানো এবং পরিবর্তিত" ফাইলের ইতিহাস হারাবেন। আমি কি সঠিক?

— elysch

-আর - বিপরীত, আমি উত্তরটি আরও স্ব-ডকুমেন্টিং হতে আপডেট করেছিলাম।

— এলিজা লিন

আপনি মার্জ করার চেষ্টা করছেন এমন ফাইলগুলি যদি আগত শাখায় মুছে ফেলা হয় তবে এটি কাজ করবে বলে মনে হচ্ছে না।

— সলিউজিং

Answer 10

কেন এটির অস্তিত্ব নেই?

আমি কীভাবে অনুকরণ করতে পারি " অন্যর মতো একটি শাখা তৈরির জন্য গিট কমান্ড " এ উল্লেখ করার সময় git merge -s theirs, দ্রষ্টব্য যে গিট 2.15 (Q4 2017) এখন আরও পরিষ্কার হয়েছে:

-X<option>মার্জগুলির জন্য ' ' এর জন্য ডকুমেন্টেশন বিভ্রান্তিকরভাবে " -s theirs" উপস্থিত থাকার পরামর্শ দেওয়ার জন্য লেখা হয়েছিল , যা ঘটনাটি নয়।

দেখুন c25d98b কমিট দ্বারা (25 সেপ্টেম্বর 2017) junio সি Hamano ( gitster) ।
^{(দ্বারা একীভূত junio সি Hamano - gitster- মধ্যে কমিট 4da3e23 , 28 সেপ্টেম্বর 2017)}

মার্জ-কৌশল: " -s theirs" বিদ্যমান আছে তা বোঝাতে এড়াতে "

-Xoursমার্জ বিকল্পের বিবরণটির একটি প্যারেন্থিকাল নোট রয়েছে যা পাঠকদের জানায় যে এটি থেকে খুব আলাদা -s ours, যা সঠিক, তবে এর বর্ণনার পরে -Xtheirsএটি অযত্নে বলেছে "এটি এর বিপরীত ours", পাঠকদেরও এটির একটি ভুল ধারণা প্রদান করে যা পাঠকদেরও প্রয়োজন সতর্ক করে দেওয়া উচিত যে এটি থেকে খুব আলাদা -s theirs, যা বাস্তবে এমনকি বিদ্যমান নেই।

-Xtheirsপুনরুক্তি কৌশল প্রয়োগ একটি কৌশল বিকল্প । এর অর্থ হ'ল পুনরাবৃত্ত কৌশলটি এখনও যা কিছু করতে পারে তা মার্জ করে দেবে এবং theirsদ্বন্দ্বের ক্ষেত্রে কেবল " " যুক্তিতে ফিরে যাবে ।

theirsএকীভূত কৌশলটির দক্ষতা বা না করার জন্য সেই বিতর্কটি সম্প্রতি এই সেপ্টেম্বর, 2017 থ্রেডে ফিরিয়ে আনা হয়েছিল ।
এটি পুরানো (2008) থ্রেডকে স্বীকৃতি দেয়

সংক্ষেপে, পূর্ববর্তী আলোচনার সংক্ষিপ্ত বিবরণ "আমরা চাই না -s theirs" কারণ এটি ভুল কর্মপ্রবাহকে উত্সাহ দেয় "।

এটির নাম উল্লেখ করা হয়েছে:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

ইয়ারোস্লাভ হালচেনকো আরও একবার সেই কৌশলটির পক্ষে সমর্থন করার চেষ্টা করেছিলেন, তবে জুনিও সি হামানো আরও বলেছেন :

আমাদের এবং তাদের প্রতিসাম্য না হওয়ার কারণ হ'ল আপনি এবং আপনি নন --- আমাদের ইতিহাস এবং তাদের ইতিহাসের নিয়ন্ত্রণ এবং মালিকানা প্রতিসম নয়।

একবার আপনি সিদ্ধান্ত নিলেন যে তাদের ইতিহাস মূল লাইন, আপনি বরং আপনার বিকাশের রেখাকে একটি পাশের শাখা হিসাবে বিবেচনা করতে এবং সেই দিকটিতে একীভূত করতে চাইবেন, ফলে ফলাফলের মার্জটির প্রথম অভিভাবক তাদের ইতিহাসের প্রতিশ্রুতিবদ্ধ এবং দ্বিতীয় পিতামাতা আপনার ইতিহাসের শেষ খারাপ। সুতরাং আপনি checkout their-history && merge -s ours your-historyপ্রথম পিতৃত্বকে বুদ্ধিমান রাখতে " " ব্যবহার করে শেষ করবেন ।

এবং এই মুহুর্তে, " -s ours" এর অভাবের জন্য " -s theirs" এর ব্যবহার আর কার্যকর নয় ।
এটি কাঙ্ক্ষিত শব্দার্থবিদ্যার যথাযথ অংশ, যেমন বেঁচে থাকা আধ্যাত্মিক ইতিহাস রেখার দৃষ্টিকোণ থেকে, আপনি এটি কী করেছিলেন তা সংরক্ষণ করতে চান, ইতিহাসের অন্যান্য রেখাটি কী করেছিল তা বাতিল করে দিয়েছিল ।

জুনিও যোগ করেছেন, মাইক বিটনের মন্তব্য হিসাবে :

git merge -s ours <their-ref>কার্যকরভাবে বলেছে ' <their-ref>স্থায়ীভাবে উপেক্ষা করার প্রতিশ্রুতি হিসাবে তাদের শাখায় করা চিহ্নগুলি চিহ্নিত করুন ";
এবং এটি গুরুত্বপূর্ণ কারণ, যদি আপনি পরবর্তীকালে তাদের শাখার পরবর্তী রাজ্যগুলি থেকে মার্জ করেন তবে তাদের পরবর্তী পরিবর্তনগুলি কখনও এড়ানো উপেক্ষা করা পরিবর্তন ছাড়াই আনা হবে ।

Comments

এটি একটি দরকারী উত্তর, তবে এটিতে একটি মূল বিষয় উল্লেখ করা হয়নি যা আমি জুনিও সি থেকে বুঝতে পেরেছি হামানো এর উত্তর: git merge -s ours <their-ref>কার্যকরভাবে বলেছে যে 'তাদের শাখায় <their-ref> পর্যন্ত করা চিহ্নগুলি স্থায়ীভাবে উপেক্ষা করার প্রতিশ্রুতি হিসাবে বলেছে' '; এবং এটি গুরুত্বপূর্ণ কারণ, যদি আপনি পরবর্তীকালে তাদের শাখার পরবর্তী রাজ্যগুলি থেকে মার্জ করেন তবে তাদের পরবর্তী পরিবর্তনগুলি কখনও এড়ানো উপেক্ষা না করেই আনা হবে

— মাইকবিটেন

@ মাইকবিটেন ধন্যবাদ আরও দৃশ্যমানতার জন্য আমি আপনার মন্তব্যে উত্তরে অন্তর্ভুক্ত করেছি।

— ভনসি

Answer 11

দেখুন junio Hamano এর ব্যাপকভাবে উদাহৃত উত্তর : আপনি অঙ্গীকারবদ্ধ বিষয়বস্তু বাতিল করতে যাচ্ছেন, তাহলে শুধু করে বাতিল, অথবা কোন হারে প্রধান ইতিহাসের এটা খুঁজে রাখা। ভবিষ্যতে পড়া সবাই কেন বিরক্ত হয় যে অফারগুলিতে কিছু নেই তারকম বার্তাগুলি কমিট করে?

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

(সম্পাদনা: বাহ, আমি কি আগে এই ভুলটি পরিচালনা করতে পারি? এটি কাজ করে))

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Answer 12

এটির একটি গিট প্লাম্বিং কমান্ড রিড-ট্রি ব্যবহার করে তবে একটি সংক্ষিপ্ত সামগ্রিক কর্মপ্রবাহ তৈরি করে।

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Answer 13

এটি আপনার নতুন ব্র্যাঙ্ককে বিদ্যমান বেসব্র্যাঞ্চে একীভূত করবে

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Comments

আমি git commit --amendআপনার উদাহরণের শেষে যুক্ত করার পরামর্শ দিচ্ছি বা ব্যবহারকারীরা একত্রীকরণের প্রতিশ্রুতিটি দেখতে git logএবং অপারেশনটি সম্পূর্ণ হয়েছে বলে ধরে নিতে পারে।

— মাইকেল আর

Answer 14

আমি মনে করি আপনি আসলে যা চান তা হ'ল:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

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

Answer 15

সমান (যা পিতামাতার আদেশ রাখে) 'গিট মার্জ করে তাদের শাখার বি'তে দেয়

মার্জ করার আগে:

!!! আপনি পরিষ্কার অবস্থায় আছেন তা নিশ্চিত করুন !!!

মার্জ করুন:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

আমরা কি করেছি? আমরা একটি নতুন প্রতিশ্রুতি তৈরি করেছি যা দুটি পিতা-মাতা আমাদের এবং তাদের এবং প্রতিশ্রুতিটির কনটনেটটি শাখাবি - তাদের

মার্জ হওয়ার পরে:

আরো স্পষ্ট করে:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Answer 16

এই উত্তরটি পল প্লেডিজ দিয়েছেন। আমি কেবল তার আদেশগুলি নিয়েছি এবং সুবিধার জন্য একটি গিট ওরফে তৈরি করেছি।

আপনার .gitconfig সম্পাদনা করুন এবং নিম্নলিখিত যুক্ত করুন:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

তারপরে আপনি চালিয়ে "গিট একীভূত করতে পারেন তাদের এ":

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Answer 17

একটি সাম্প্রতিক ইতিহাস ভাগ করে নেওয়ার জন্য দুটি পৃথক সংগ্রহস্থলের জন্য আমার সম্প্রতি এটি করা দরকার। আমি দিয়ে শুরু:

• Org/repository1 master
• Org/repository2 master

আমি চেয়েছিলাম যে সমস্ত পরিবর্তনগুলি repository2 masterপ্রয়োগ করা হোক repository1 master, সংগ্রহস্থল 2 যে সমস্ত পরিবর্তনগুলি গ্রহণ করবে তা গ্রহণ করে। গিটের ভাষায়, এটি একটি কৌশল হওয়া উচিত যা বলা হয় -s theirsকিন্তু এটি বিদ্যমান না। সাবধান থাকুন কারণ -X theirsএটি যেমন নামকরণ করা হয়েছে ঠিক তেমনই চান তবে এটিও একই নয় (এটি ম্যান পৃষ্ঠায়ও বলা হয়েছে)।

আমি এটি সমাধান করার উপায়টি ছিল repository2একটি নতুন শাখা তৈরি করা repo1-merge। এই শাখায়, আমি দৌড়েছি git pull [e-mail]:Org/repository1 -s oursএবং এটি কোনও সমস্যা ছাড়াই সূক্ষ্মভাবে একীভূত হয়। আমি তখন এটি রিমোটে ধাক্কা।

তারপরে আমি ফিরে গিয়ে repository1একটি নতুন শাখা তৈরি করব repo2-merge। এই শাখায়, আমি চালিত git pull [e-mail]:Org/repository2 repo1-mergeযা ইস্যুগুলির সাথে সম্পূর্ণ হবে।

শেষ অবধি, আপনাকে repository1এটি নতুন মাস্টার হিসাবে তৈরি করার জন্য মার্জ করার অনুরোধ জারি করতে হবে, বা কেবল একটি শাখা হিসাবে রাখতে হবে।

Answer 18

একটি সহজ এবং স্বজ্ঞাত (আমার মতে) এটি করার দ্বি-পদক্ষেপ

git checkout branchB .
git commit -m "Picked up the content from branchB"

অনুসরণ করেছে

git merge -s ours branchB

(যা দুটি শাখাকে মার্জড হিসাবে চিহ্নিত করে)

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

এই পদ্ধতিটি পুনর্বিবেচনার লগ থেকে এটি পরিষ্কার হয়েছিল যে পরে কী করা হয়েছিল - এবং কী উদ্দেশ্য ছিল।

Comments

এটি মূল প্রশ্নের জন্য সঠিক হতে পারে, তবে ওপি ২০০৮ সালে প্রশ্নটি এমনভাবে আপডেট করেছিল যাতে এই উত্তরটি ভুল।

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

@ ব্যবহারকারী 3338098 হ্যাঁ, এমন করুণাময় যে তারা বিভ্রান্তিমূলক শিরোনাম ছেড়ে গেছে এবং প্রশ্ন সংস্থার শেষে একটি দৃশ্যমান আপডেটকে চড় মেরেছিল .... কারণ এই উত্তরগুলি শিরোনাম প্রশ্নের সঠিক উত্তর দেয় ।

— রোমান ভ্যালারি

আমি

— @