एक शाखा को दूसरी की तरह बनाने के लिए git कमांड


81

मैं बदलावों के साथ एक शाखा लेने की कोशिश कर रहा हूं और इसे वापस ऊपर लाने के लिए समान होने के लिए ला रहा हूं। परिवर्तन दोनों स्थानीय हैं और उन्हें जीथब में धकेल दिया गया है, इसलिए न तो git resetया git rebaseवास्तव में व्यवहार्य है, क्योंकि वे इतिहास बदलते हैं, जो एक शाखा के साथ एक बुरी चीज है जिसे पहले से ही धक्का दिया गया है।

मैंने git mergeविभिन्न रणनीतियों के साथ भी कोशिश की है, लेकिन उनमें से कोई भी स्थानीय परिवर्तन को पूर्ववत् नहीं करता है, अर्थात यदि मैंने कोई फ़ाइल जोड़ी है, तो मर्ज अन्य फ़ाइलों को पंक्ति में ला सकता है, लेकिन मेरे पास अभी भी वह फ़ाइल है जो अपस्ट्रीम में नहीं है है।

मैं सिर्फ एक नई शाखा बना सकता हूं, लेकिन मैं वास्तव में एक मर्ज चाहूंगा कि संशोधन के संदर्भ में इतिहास मेरी शाखा को लेने और फिर से ऊपर के समान होने के लिए सभी परिवर्तनों को लागू करता है, ताकि मैं उस परिवर्तन को सुरक्षित रूप से धक्का दे सकूं बिना क्लोबिंग के इतिहास। क्या ऐसी कोई कमांड या सीरीज़ की सीरीज़ है?


9
यदि आप परिवर्तनों को संरक्षित करने के बारे में परवाह नहीं करते हैं, तो बस शाखा को हटाएं और फिर से क्यों न बनाएं? "परियोजना का इतिहास" पवित्र होने की आवश्यकता नहीं है। Git डेवलपर्स को संवाद करने में मदद करने के लिए एक उपकरण है। यदि ये परिवर्तन मदद नहीं करते हैं, तो उन्हें फेंक दें।
wnoise

+100 @wnoise - खासकर अगर बदलाव पहले ही मिल गए हों।
wuputah

7
मुझे इतिहास को संरक्षित करने की परवाह है क्योंकि यह सहयोग के लिए प्रकाशित है और मैं इसे वापस जाना चाहता हूं। यदि आप केवल नवीनतम रखते हैं तो संशोधन नियंत्रण का उपयोग करके परेशान क्यों हों?
अर्ने क्लेसेन

1
यह एक व्यक्तिपरक तर्क है, लेकिन मेरे लिए, एक वीसीएस का उद्देश्य परियोजना के इतिहास के हर माइनुटिया को रिकॉर्ड करना नहीं है, बल्कि केवल सामग्री (परिवर्तन) में परिवर्तन रिकॉर्ड करने के लिए है, जिससे आप पेड़ / इतिहास को हेरफेर कर सकें। उन कमिट्स (ब्रांचिंग, मर्जिंग, रीबासिंग, रिसेटिंग, आदि) पर, और आपको इतिहास के आधार पर रिपोर्ट देखने की अनुमति देता है (भिन्न, लॉग, दोष, आदि)। गिट "बेवकूफ सामग्री ट्रैकर" है - मैं इसे स्रोत कोड को प्रबंधित करने के लिए एक उपकरण के रूप में देखता हूं, टाइम मशीन नहीं।
वुपुतह

5
जैसा कि आपने कहा, यह व्यक्तिपरक है। मैं परित्यक्त दृष्टिकोणों की समीक्षा करने में सक्षम होने के बारे में परवाह करता हूं, और यह देखने में सक्षम हूं कि अतीत में किसी समय क्या निर्णय किए गए थे। और मुझे परवाह है कि कुछ त्यागने का मेरा निर्णय मर्ज बिंदुओं को नष्ट नहीं करता है, जो दूसरों को इंगित कर सकते हैं।
Arne क्लेसेन

जवाबों:


107

आप अपनी अपस्ट्रीम शाखा को अपनी devशाखा में मर्ज कर सकते हैं , एक कस्टम मर्ज ड्राइवर के साथ "KeepTheirs" :
देखें " " git merge -s theirs"आवश्यक" - लेकिन मुझे पता है कि यह मौजूद नहीं है "।
आपके मामले में, केवल एक की .gitattributesआवश्यकता होगी, और एक keepTheirsस्क्रिप्ट जैसी:

mv -f $3 $2
exit 0

git merge --strategy=theirs अनुकरण # १

पहले माता-पिता के रूप में अपस्ट्रीम के साथ मर्ज के रूप में दिखाता है।

Jefromi का उल्लेख है (टिप्पणियों में) merge -s ours, अपस्ट्रीम (या अपस्ट्रीम से शुरू होने वाली एक अस्थायी शाखा) पर अपने काम का विलय करके, और फिर उस विलय के परिणाम के लिए अपनी शाखा को तेज़ी से अग्रेषित करें:

git checkout -b tmp origin/upstream
git merge -s ours downstream         # ignoring all changes from downstream
git checkout downstream
git merge tmp                        # fast-forward to tmp HEAD
git branch -D tmp                    # deleting tmp

इससे पहले अभिभावक के रूप में अपस्ट्रीम पूर्वज को रिकॉर्ड करने का लाभ होता है, ताकि मर्ज का अर्थ "इस विषय शाखा को नष्ट करने" के बजाय "इस आउट-ऑफ-डेट विषय शाखा को अवशोषित करें" और इसे अपस्ट्रीम से बदल दें

(2011 का संपादन):

ओपी द्वारा इस ब्लॉग पोस्ट में इस वर्कफ़्लो की सूचना दी गई है :

मुझे फिर से ऐसा क्यों चाहिए?

जब तक मेरे रेपो का सार्वजनिक संस्करण से कोई लेना-देना नहीं था, तब तक यह सब ठीक था, लेकिन अब चूंकि मैं अन्य टीम के सदस्यों और बाहर के योगदानकर्ताओं के साथ WIP पर टकराने की क्षमता चाहता हूं, इसलिए मैं यह सुनिश्चित करना चाहता हूं कि मेरी सार्वजनिक शाखाएं हैं दूसरों के लिए ब्रांच को बंद करने और खींचने से विश्वसनीय, यानी कोई और रिबास और उन चीजों पर रीसेट न करें जिन्हें मैंने रिमोट बैकअप पर धकेल दिया है, क्योंकि यह अब GitHub और पब्लिक पर है।

इसलिए मुझे छोड़ देना चाहिए कि मुझे कैसे आगे बढ़ना चाहिए।
99% समय मेरी कॉपी अपस्ट्रीम मास्टर में जाएगा, इसलिए मैं अपने मास्टर को काम करना चाहता हूं और ज्यादातर समय अपस्ट्रीम में धकेलना चाहता हूं।
लेकिन हर बार एक समय में, मेरे पास जो wipकुछ भी है वह अमान्य हो जाएगा जो ऊपर की तरफ जाता है और मैं अपना कुछ हिस्सा छोड़ दूंगा wip
उस बिंदु पर मैं अपने गुरु को अपस्ट्रीम के साथ सिंक में वापस लाना चाहता हूं, लेकिन अपने सार्वजनिक रूप से धक्का दिए गए मास्टर पर किसी भी प्रतिबद्ध बिंदु को नष्ट नहीं करता। Ie मैं अपस्ट्रीम के साथ एक मर्ज चाहता हूं जो कि बदलाव के साथ समाप्त होता है जो मेरी कॉपी को अपस्ट्रीम के समान बनाता है
और यही करना git merge --strategy=theirsचाहिए।


git merge --strategy=theirs सिमुलेशन # 2

पहले माता-पिता के रूप में हमारे साथ, एक मर्ज के रूप में दिखाता है।

( jcwenger द्वारा प्रस्तावित )

git checkout -b tmp upstream
git merge -s ours thebranch         # ignoring all changes from downstream
git checkout downstream
git merge --squash tmp               # apply changes from tmp but not as merge.
git rev-parse upstream > .git/MERGE_HEAD #record upstream 2nd merge head
git commit -m "rebaselined thebranch from upstream" # make the commit.
git branch -D tmp                    # deleting tmp

git merge --strategy=theirs सिमुलेशन # 3

इस ब्लॉग में उल्लेख है :

git merge -s ours ref-to-be-merged
git diff --binary ref-to-be-merged | git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

कभी-कभी आप ऐसा करना चाहते हैं, और इसलिए नहीं कि आपके पास अपने इतिहास में "बकवास" है, बल्कि शायद इसलिए कि आप एक सार्वजनिक भंडार में विकास के लिए आधार रेखा को बदलना चाहते हैं, जहां रिबासिंग से बचा जाना चाहिए


git merge --strategy=theirs सिमुलेशन # 4

(वही ब्लॉग पोस्ट)

वैकल्पिक रूप से, यदि आप स्थानीय अपस्ट्रीम शाखाओं को तेजी से आगे रखना चाहते हैं, तो एक संभावित समझौता इस समझ के साथ काम करना है कि फुट / अस्थिर के लिए, अपस्ट्रीम शाखा समय-समय पर रीसेट / विद्रोहित हो सकती है (घटनाओं के आधार पर जो अंततः समाप्त हो गई है) अपस्ट्रीम प्रोजेक्ट के पक्ष पर आपके नियंत्रण का)।
यह एक बड़ी बात नहीं है और इस धारणा के साथ काम करने का मतलब है कि स्थानीय अपस्ट्रीम शाखा को ऐसी स्थिति में रखना आसान है जहां यह केवल तेजी से अग्रेषित अपडेट लेता है।

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff --binary ref-to-be-merged | git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

git merge --strategy=theirs सिमुलेशन # 5

( बराक ए। पर्लमटर द्वारा प्रस्तावित ):

git checkout MINE
git merge --no-commit -s ours HERS
git rm -rf .
git checkout HERS -- .
git checkout MINE -- debian # or whatever, as appropriate
git gui # edit commit message & click commit button

git merge --strategy=theirs सिमुलेशन # 6

(वही माइकल गेबस्ट्रोस द्वारा प्रस्तावित ):

माइकल गेबट्र्रो ने इसमें धोखा दिया, यह दावा करते हुए कि मैं "धोखा" दे रहा था;) और निचले-स्तर की पाइपलाइन के साथ एक और समाधान दिया:

(यह git नहीं होगा यदि यह केवल git कमांड के साथ संभव नहीं होगा, तो अंतर / पैच के साथ git में सब कुछ एक वास्तविक समाधान है;)।

# get the contents of another branch
git read-tree -u --reset <ID>
# selectivly merge subdirectories
# e.g superseed upstream source with that from another branch
git merge -s ours --no-commit other_upstream
git read-tree --reset -u other_upstream     # or use --prefix=foo/
git checkout HEAD -- debian/
git checkout HEAD -- .gitignore
git commit -m 'superseed upstream source' -a

git merge --strategy=theirs सिमुलेशन # 7

आवश्यक कदम के रूप में वर्णित किया जा सकता है:

  1. अपने वर्कट्री को अपस्ट्रीम से बदलें
  2. सूचकांक में परिवर्तन लागू करें
  3. दूसरे अभिभावक के रूप में अपस्ट्रीम जोड़ें
  4. कमिट

आदेश git read-treeएक अलग पेड़ के साथ सूचकांक को अधिलेखित करता है, दूसरे चरण को पूरा करता है , और पहले चरण को पूरा करते हुए काम के पेड़ को अपडेट करने के लिए झंडे होते हैं । कमिट करते समय, git दूसरे माता-पिता के रूप में .IT / MERGE_HEAD में SHA1 का उपयोग करता है, इसलिए हम इसे मर्ज कमिट बनाने के लिए पॉप्युलेट कर सकते हैं। इसलिए, यह पूरा किया जा सकता है:

git read-tree -u --reset upstream                 # update files and stage changes
git rev-parse upstream > .git/MERGE_HEAD          # setup merge commit
git commit -m "Merge branch 'upstream' into mine" # commit

7
आप हमेशा उनकी जगह सिर्फ हमारा उपयोग कर सकते हैं: दूसरी शाखा देखें, उसमें आपका विलय कर दें, फिर आपका विलय करने के लिए तेजी से अग्रेषित करें। git checkout upstream; git merge -s ours downstream; git checkout downstream; git merge upstream। (यदि आवश्यक हो तो अपस्ट्रीम पर एक अस्थायी शाखा का उपयोग करें।) यह पहला अभिभावक के रूप में अपस्ट्रीम पूर्वज को रिकॉर्ड करने का लाभ है, ताकि मर्ज का अर्थ "इस विषय शाखा को नष्ट करने और बदलने के बजाय" इस आउट-ऑफ-डेट विषय शाखा को अवशोषित करें " ऊपर के साथ "।
Cascabel

@ जेफ्रोमी: उत्कृष्ट बिंदु, हमेशा की तरह। मैंने इसे अपने उत्तर में शामिल किया है।
वॉनक

एक अन्य विकल्प - जैसे git मर्ज --strategy = उनकी सिमुलेशन # 1 - इसके अलावा ब्रांच को पहले मर्ज अभिभावक के रूप में संरक्षित करता है: git checkout -b tmp उत्पत्ति / अपस्ट्रीम git मर्ज -s हमारा-डाउनस्ट्रीम नीचे की ओर से सभी परिवर्तनों को अनदेखा करता है। checkout डाउनस्ट्रीम git मर्ज --squash tmp # tmp से परिवर्तन लागू करें, लेकिन मर्ज के रूप में नहीं। git Rev-parse upstream> .it / MERGE_HEAD #record अपस्ट्रीम दूसरा मर्ज हेड git कमिट -m "upaselined ours from upstream" # कमिट करें। गिट ब्रांच -D tmp # डिलीट tmp
jcwenger

2
वाह, किसने सोचा होगा कि --strategy = उनके इतने तरीकों से लागू किया जा सकता है। अब अगर यह सिर्फ git के अगले संस्करण में हो सकता है
Arne Claassen

VonC और उनका ज्ञान आश्चर्यजनक है। वह जॉन की तरह है। :)
16'13

13

यह मुझे लगता है जैसे आपको बस करने की ज़रूरत है:

$ git reset --hard origin/master

यदि अपस्ट्रीम को पुश करने के लिए कोई परिवर्तन नहीं है, और आप बस अपस्ट्रीम शाखा को अपनी वर्तमान शाखा बनाना चाहते हैं, तो यह ऐसा करेगा। यह स्थानीय रूप से करना हानिकारक नहीं है, लेकिन आप किसी भी स्थानीय परिवर्तन को खो देंगे ** जिसे मास्टर करने के लिए धक्का नहीं दिया गया है।

** वास्तव में परिवर्तन अभी भी आसपास हैं यदि आपने उन्हें स्थानीय रूप से प्रतिबद्ध किया है, क्योंकि कमिट अभी भी आपके पास होगी git reflog, आमतौर पर कम से कम 30 दिनों के लिए।


यह काम करता है यदि आपको किसी भी कीमत पर उस परिवर्तन की आवश्यकता है, क्योंकि यह शाखा के इतिहास को बदल सकता है (आपको -f के साथ धक्का देना होगा)। जिसे अवरुद्ध करने के लिए कॉन्फ़िगर किया जा सकता है, इसलिए मूल रूप से यह आपके लिए केवल निजी रिपोजिटरी का काम करेगा, व्यवहार में।
रिबमार

12

आप इसे अब आसानी से कर सकते हैं:

$ git fetch origin
$ git merge origin/master -s recursive -Xtheirs

यह मूल के साथ आपके स्थानीय रेपो-इन-सिंक को प्राप्त करता है, और इतिहास को संरक्षित करता है।


5
git merge -s recursive -Xtheirsस्वचालित रूप से बाइनरी फ़ाइलों को मर्ज नहीं करता है, इसलिए आप एक संघर्ष की स्थिति में समाप्त होते हैं जिसे आपको मैन्युअल रूप से हल करना होगा। git merge -s oursइस पर आधारित वर्कफ़्लोज़ को नुकसान नहीं होता है।
स्टेफान

यह एक खाली प्रतिबद्ध बनाने के लिए प्रकट होता है।
रॉबिन ग्रीन

मेरी माफी - यह वास्तव में काम करता है, लेकिन git showएक मर्ज कमिटमेंट में केवल संघर्ष के संकल्प दिखाई देते हैं, और अगर कोई संघर्ष संकल्प नहीं -Xtheirsहैं, तो स्पष्ट रूप से उपयोग किया जाता है।
रॉबिन ग्रीन

5

इसके लिए एक और सिमुलेशन git merge -s theirs ref-to-be-merged:

git merge --no-ff -s ours ref-to-be-merged         # enforce a merge commit; content is still wrong
git reset --hard HEAD^2; git reset --soft HEAD@{1} # fix the content
git commit --amend

डबल रिसेट का एक विकल्प रिवर्स पैच को लागू करना होगा:

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

रिवर्स पैच का दिलचस्प उपयोग। +1
VONC

रीसेट ने मेरे लिए काम नहीं किया, मुझे "घातक: अस्पष्ट तर्क 'HEAD2' मिला: अज्ञात संशोधन या काम करने वाले पेड़ में पथ नहीं।" । (हां, मैंने टाइप किया HEAD^2) पैच विधि ने काम किया।
user247702

@Stijn: सबसे अधिक संभावना है कि आपने वास्तव में ^सही ढंग से टाइप नहीं किया है। कभी-कभी "कीटल-सी" जैसे अन्य कीस्ट्रोक्स को "^ सी" के रूप में प्रदर्शित किया जाता है। - यदि आपने वास्तव में सही "^" टाइप किया है, तो आपको अपने गिट संस्करण में एक गंभीर बग मिला है।
माइक्स

विंडोज पर @michas ^ चरित्र बचने के लिए उपयोग किया जाता है, इसलिए इसे शाब्दिक रूप में उपयोग करने के लिए आपको इसे स्वयं से बचना होगा। git reset --hard HEAD^^2; git reset --soft HEAD@{1}
जोशुआ वाल्श

4

प्लंबिंग कमांड की थोड़ी मदद से भी एक तरीका है - IMHO सबसे सीधा। कहो कि आप 2 शाखाओं के मामले में "उनका" अनुकरण करना चाहते हैं:

head1=$(git show --pretty=format:"%H" -s foo)
head2=$(git show --pretty=format:"%H" -s bar)
tree=$(git show --pretty=format:"%T" -s bar)
newhead=$(git commit-tree $tree -p $head1 -p $head2 <<<"merge commit message")
git reset --hard $newhead

यह उनमें से किसी एक के वृक्ष का उपयोग करके शीर्षों की मनमानी संख्या (2 ऊपर के उदाहरण) में विलय करता है (ऊपर दिए गए उदाहरण में बार), उनका '' वृक्ष '' प्रदान करता है, जो किसी भी प्रकार / फ़ाइल के मुद्दों की अवहेलना करता है (प्रतिबद्ध-वृक्ष निम्न स्तर का आदेश है, इसलिए उन के बारे में परवाह नहीं है)। ध्यान दें कि सिर सिर्फ 1 हो सकता है (इसलिए "उनके" के साथ चेरी-पिक के बराबर)।

ध्यान दें, जो पहले माता-पिता को निर्दिष्ट किया जाता है, वह कुछ सामानों को प्रभावित कर सकता है (उदाहरण के लिए - git-log कमांड का प्रथम-माता-पिता) - इसलिए इसे ध्यान में रखें।

गिट-शो के बजाय, पेड़ और प्रतिबद्ध हैश का उत्पादन करने में सक्षम कुछ और भी इस्तेमाल किया जा सकता है - जो कुछ भी पार्स करने के लिए उपयोग किया जाता है (कैट-फाइल, रि-लिस्ट, ...)। आप git कमिट के साथ सब कुछ का पालन कर सकते हैं - अंतःक्रियात्मक रूप से सौंदर्य संदेश को सुशोभित करना।


यह मेरी नजर में सबसे सीधा है। आप कहने के लिए प्लंबिंग कमांड्स का उपयोग कर रहे हैं "इस पेड़ के साथ एक नई प्रतिबद्ध वस्तु बनाएं, यह पहला माता-पिता, यह दूसरा माता-पिता। फिर इस नई प्रतिबद्धता के लिए सिर को इंगित करें।" करने के लिए। दोष यह है कि आपको इस ऑपरेशन को काम करने के लिए 4 अलग-अलग हैश को बचाने की आवश्यकता है।
माइकल आर

2

भारी हाथ, लेकिन नरक, संभवतः क्या गलत हो सकता है?

  • शाखा X देखें जो आप वाई की तरह दिखना चाहते हैं
  • cp -r .git /tmp
  • शाखा Y देखें git checkout y
  • rm -rf .git && cp -r /tmp/.git
  • किसी भी अंतर को कमिट करें और पुश करें
  • किया हुआ।

यह दो शाखाओं को समान बनाने के लिए सबसे सरल, क्रूर बल तरीका है, यह मानते हुए कि आप मर्ज इतिहास को बनाए रखने की परवाह नहीं करते हैं।
डेमन डी

1

दूरस्थ अपस्ट्रीम शाखा में परिवर्तन और git mergeमर्ज की गई रणनीति के साथ करें ours

git checkout origin/master
git merge dev --strategy=ours
git commit ...
git push

सभी इतिहास अभी भी मौजूद होंगे, लेकिन आपके पास एक अतिरिक्त मर्ज कमिटमेंट होगा। यहाँ महत्वपूर्ण बात यह है कि जिस संस्करण को आप बनना चाहते हैं oursउससे शुरू करें और शाखा जीथूब के साथ विलय करें।


1
मुझे इसके विपरीत चाहिए। यह मेरी शाखा लेगा और इसे अपस्ट्रीम में एकीकृत करेगा, लेकिन अपस्ट्रीम हेड को अपरिवर्तित छोड़ देगा। लेकिन मुझे अपस्ट्रीम लेने की जरूरत है और इसे अपनी शाखा में एकीकृत करने के लिए मेरे सिर को ऊपर की तरफ देखना चाहिए। मूल रूप से कुछ पसंद है --strategy=theirs, सिवाय निकटतम --strategy=recursive -X=theirsकाफी ऐसा नहीं करता है।
अर्ने क्लेसेन

--strategy=theirsके ठीक विपरीत है --strategy=ours। आप विपरीत छोर से शुरू करते हैं (इसलिए जीथब से शुरू करें और दूसरे तरीके से विलय करें)।
केलोटी

नहीं है --strategy=theirs, जो समस्या है। निकटतम, --strategy=recursive -X theirsजो काफी विपरीत नहीं है, क्योंकि यह बाहरी स्थानीय परिवर्तनों को दूर नहीं करेगा, अगर वे संघर्ष नहीं करते हैं।
अर्ने क्लेसेन

ये दो विपरीत हैं: git checkout dev; git merge origin/master --strategy=oursऔरgit checkout origin/master; git merge dev --strategy=ours
wuputah

2
@Arne: VonC के जवाब पर मेरी टिप्पणी देखें। oursरणनीति की उपस्थिति एक theirsरणनीति करने के लिए पूरी तरह से संभव बनाती है ।
Cascabel

1

Git रीसेट BACKWARDS का उपयोग करें!

आप किसी भी अन्य के साथ की तरह एक शाखा देखो बना सकते हैं git reset, लेकिन आप इसे एक दौर के बारे में करना होगा।

कमिट <old>की तरह एक शाखा बनाने के लिए <new>, आप कर सकते हैं

git reset --hard <new>

<new>काम करने वाले पेड़ की सामग्री बनाने के लिए।

फिर करो

git reset --mixed <old> 

राज्य में वापस काम करने वाले पेड़ को मूल प्रतिबद्ध करने के लिए शाखा को बदलने के लिए ।<new>

फिर आप अपनी शाखा को <new>कमिट की सामग्री से पूरी तरह से मेल खाने के लिए इसमें बदलाव जोड़ सकते हैं और कर सकते हैं ।

यह काउंटर सहज है कि से स्थानांतरित करने के लिए <old>राज्य के लिए <new>आप एक करने की ज़रूरत git reset से <new> करने के लिए <old> । हालांकि विकल्प --mixedके साथ काम करने वाले पेड़ को छोड़ दिया जाता है <new>और शाखा सूचक को सेट किया जाता है <old>, ताकि जब परिवर्तन प्रतिबद्ध हों तो शाखा को यह दिखे कि हम कैसे चाहते हैं।

चेतावनी

अपने कमिट्स का ट्रैक न खोएं, उदाहरण के लिए यह भूल जाएं कि क्या करना <old>है git reset --hard <new>


0

मैंने उन भूमिकाओं का पालन किया:

उत्पत्ति प्राप्त करना, शाखा से हार्ड रीसेट करना, फिर उनकी पुनरावृत्ति और फिर शाखा को धक्का देने के लिए मजबूर करना

अपने खुद के जोखिम पर

git fetch origin
git reset --hard origin/<branch>
git merge origin/<branch> -s recursive -Xtheirs
git push -f <remote> <branch>
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.