चेकआउट का उपयोग किए बिना Git शाखाओं को मर्ज करना, अपडेट करना और खींचना

Question

मैं एक ऐसी परियोजना पर काम करता हूं जिसमें 2 शाखाएं हैं, ए और बी। मैं आमतौर पर शाखा ए पर काम करता हूं, और शाखा बी से सामान को मर्ज करने के लिए, मैं आमतौर पर करता हूं:

git merge origin/branchB

हालाँकि, मैं शाखा बी की एक स्थानीय प्रति भी रखना चाहूंगा, क्योंकि मैं कभी-कभार अपनी शाखा ए के साथ पहली बार विलय किए बिना शाखा की जांच कर सकता हूं। इसके लिए, मैं यह करूंगा:

git checkout branchB
git pull
git checkout branchA

क्या एक कमांड में ऊपर करने का एक तरीका है, और शाखा को आगे और पीछे स्विच किए बिना? क्या मुझे उसके लिए उपयोग करना चाहिए git update-ref? कैसे?

Comments

संबं धत

— लं क

पहले लिंक किए गए सवाल के लिए जैकब का जवाब बताता है कि यह सामान्य रूप से असंभव क्यों है। एक और (पोस्टवर्डी) स्पष्टीकरण यह है कि आप एक नंगे रेपो में विलय नहीं कर सकते हैं, इसलिए स्पष्ट रूप से इसे काम के पेड़ की आवश्यकता होती है।

— कैस्केबेल

@ एरिक: सामान्य कारण यह है कि बड़े रिपॉजिट के लिए चेकआउट समय लेने वाली हैं, और यह कि वे टाइमस्टैम्प को अपडेट करते हैं भले ही आप एक ही संस्करण में लौटते हैं, इसलिए यह सोचें कि सब कुछ पुनर्निर्माण करने की आवश्यकता है।

— कास्केबेल

दूसरा प्रश्न जो मैंने जोड़ा है, वह एक असामान्य मामले के बारे में पूछ रहा है - विलय जो तेजी से आगे की ओर हो सकता है, लेकिन जो ओपी --no-ffविकल्प का उपयोग करके विलय करना चाहता था , जो मर्ज कमिटमेंट को वैसे भी दर्ज करने का कारण बनता है। क्या आपको इसमें दिलचस्पी लेनी चाहिए, मेरा जवाब वहां दिखाया गया है कि आप ऐसा कैसे कर सकते हैं - यहाँ मेरे पोस्ट किए गए उत्तर के रूप में बहुत मजबूत नहीं है, लेकिन दोनों की ताकत निश्चित रूप से संयुक्त हो सकती है।

— कैस्केबेल

कार्य निर्देशिका को बदले बिना विलय को भी देखें ।

Answer 1

संक्षिप्त उत्तर

जब तक आप एक तेजी से आगे मर्ज कर रहे हैं , तब तक आप बस उपयोग कर सकते हैं

git fetch <remote> <sourceBranch>:<destinationBranch>

उदाहरण:

# Merge local branch foo into local branch master,
# without having to checkout master first.
# Here `.` means to use the local repository as the "remote":
git fetch . foo:master

# Merge remote branch origin/foo into local branch foo,
# without having to checkout foo first:
git fetch origin foo:foo

जबकि एम्बर का जवाब फास्ट-फॉरवर्ड मामलों में भी काम करेगा, git fetchइसके बजाय ब्रांच-रेफ़रेंस को बलपूर्वक स्थानांतरित करने की तुलना में थोड़ा सुरक्षित है, क्योंकि git fetchस्वचालित रूप से जब तक आप उपयोग नहीं करते तब तक आकस्मिक गैर-फास्ट-फॉरवर्ड को रोक दिया जाएगा +। refspec।

दीर्घ उत्तर

यदि आप गैर-फास्ट-फ़ॉरवर्ड-मर्ज में परिणाम होंगे, तो आप पहले A की जाँच के बिना एक शाखा B को शाखा A में विलय नहीं कर सकते। ऐसा इसलिए है क्योंकि किसी भी संभावित संघर्ष को हल करने के लिए एक कार्यशील प्रतिलिपि की आवश्यकता होती है।

हालांकि, फास्ट-फॉरवर्ड मर्ज के मामले में, यह संभव है , क्योंकि इस तरह के मर्ज का परिणाम कभी भी संघर्ष में नहीं हो सकता है। पहले एक शाखा की जांच के बिना ऐसा करने के लिए, आप git fetchएक रीस्पेक के साथ उपयोग कर सकते हैं ।

masterयदि आपके पास एक और शाखा featureहै, तो अपडेट करने का एक उदाहरण है (गैर-तेज़-फ़ॉरवर्ड परिवर्तन को रोकना)।

git fetch upstream master:master

यह उपयोग-मामला इतना सामान्य है, कि आप शायद अपनी git कॉन्फ़िगरेशन फ़ाइल में इसके लिए एक उपनाम बनाना चाहेंगे, जैसे यह:

[alias]
    sync = !sh -c 'git checkout --quiet HEAD; git fetch upstream master:master; git checkout --quiet -'

यह उपनाम क्या करता है:

1. git checkout HEAD: यह आपकी वर्किंग कॉपी को अलग-अलग स्थिति में रखता है। यह उपयोगी है यदि आप अद्यतन करना चाहते हैं masterजबकि आप इसे चेक-आउट करना चाहते हैं। मुझे लगता है कि ऐसा करना आवश्यक था क्योंकि अन्यथा के लिए शाखा संदर्भ masterनहीं चलेगा, लेकिन मुझे याद नहीं है कि यह वास्तव में मेरे सिर के ठीक ऊपर-ऊपर है।

2. git fetch upstream master:master: यह फास्ट-फॉरवर्ड आपके स्थानीय masterके रूप में उसी स्थान पर है upstream/master।

3. git checkout -अपनी पहले से चेक-आउट शाखा की जाँच करता है (कि -इस मामले में क्या करता है)।

git fetch(गैर-) फास्ट-फ़ॉरवर्ड मर्ज का सिंटैक्स

यदि आप चाहते हैं कि fetchयदि अपडेट नॉन-फास्‍ट-फारवर्ड हो तो कमांड फेल हो जाए, तो आप बस फॉर्म के रीस्पेक का उपयोग करें

git fetch <remote> <remoteBranch>:<localBranch>

यदि आप गैर-फास्ट-फॉरवर्ड अपडेट की अनुमति देना चाहते हैं, तो आप +रिफस्पेक के सामने एक जोड़ दें:

git fetch <remote> +<remoteBranch>:<localBranch>

ध्यान दें कि आप अपने स्थानीय रेपो को "रिमोट" पैरामीटर का उपयोग करके पास कर सकते हैं .:

git fetch . <sourceBranch>:<destinationBranch>

दस्तावेज़ीकरण

git fetchइस सिंटैक्स की व्याख्या करने वाले प्रलेखन से (जोर मेरा):

<refspec>

एक <refspec>पैरामीटर का प्रारूप एक वैकल्पिक प्लस है +, इसके बाद स्रोत रेफ <src>, एक कोलन द्वारा पीछा किया जाता है :, उसके बाद गंतव्य रेफरी <dst>।

जो रिमोट रेफरी मैच करता <src>है, वह लाया जाता है, और यदि <dst>खाली स्ट्रिंग नहीं है, तो स्थानीय मिलान जो इसे मेल खाता है, तेजी से अग्रेषित करता है<src> । यदि वैकल्पिक प्लस+का उपयोग किया जाता है, तो स्थानीय रेफरी को अपडेट किया जाता है, भले ही यह फास्ट-फॉरवर्ड अपडेट में न हो।

यह सभी देखें

1. काम के पेड़ को छूने के बिना चेकआउट और मर्ज करें

2. कार्य निर्देशिका को बदले बिना विलय करना

Comments

git checkout --quiet HEADहै git checkout --quiet --detachGit 1.7.5 के रूप में।

— रफा

मैंने पाया कि मुझे ऐसा करना था: git fetch . origin/foo:fooअपने स्थानीय फू को अपने स्थानीय मूल / फू में अपडेट करने के लिए

— वेस्टन

क्या एक कारण "git चेकआउट HEAD --quiet" और "git checkout --quiet -" भाग लंबे उत्तर में शामिल हैं, लेकिन संक्षिप्त उत्तर नहीं है? मुझे लगता है कि ऐसा इसलिए है क्योंकि स्क्रिप्ट को तब चलाया जा सकता है जब आप मास्टर चेक आउट कर चुके हों, भले ही आप सिर्फ एक गिट पुल कर सकें?

— सीन

यहाँ 'मर्ज' करने की आज्ञा क्यों दी गई है ... इसका कोई मतलब नहीं है; यदि 'पुल' 'मर्ज' है, उसके बाद 'मर्ज' है, तो एक और तार्किक 'मर्ज-ff-only' समतुल्य होना चाहिए, जो स्थानीय रूप से 'मूल / शाखा' से 'ब्रांच' को अपडेट करेगा, यह देखते हुए कि 'ब्रांच' है पहले से ही चलाया जा रहा है।

— एड रैंडल

git checkout -चाल के लिए धन्यवाद ! बस के रूप में आसान है cd -।

— घोड़ा

Answer 2

नहीं वहाँ नहीं है। लक्ष्य शाखा का एक चेकआउट आपको अन्य चीजों के बीच संघर्ष को हल करने की अनुमति देने के लिए आवश्यक है (यदि गिट उन्हें स्वचालित रूप से विलय करने में असमर्थ है)।

हालांकि, यदि मर्ज वह है जो तेजी से आगे होगा, तो आपको लक्ष्य शाखा की जांच करने की आवश्यकता नहीं है, क्योंकि आपको वास्तव में कुछ भी विलय करने की आवश्यकता नहीं है - आपको बस इतना करना है कि शाखा को इंगित करने के लिए अपडेट करना होगा। नया सिर रेफरी। आप इसके साथ कर सकते हैं git branch -f:

git branch -f branch-b branch-a

branch-bके प्रमुख को इंगित करने के लिए अद्यतन करेगा branch-a।

-fविकल्प के लिए खड़ा है --force, जिसका अर्थ है आप सावधान जब इसे का उपयोग किया जाना चाहिए।

इसका उपयोग तब तक न करें जब तक कि आप पूरी तरह से सुनिश्चित नहीं हो जाते हैं कि मर्ज तेजी से आगे होगा।

Comments

बस ऐसा करने के लिए बहुत सावधान रहें जब तक कि आपने पूरी तरह से सुनिश्चित नहीं किया है कि मर्ज तेजी से आगे होगा! बाद में महसूस करना चाहते हैं कि आपने गलत तरीके से काम किया है।

— कास्केबेल

@FuadSaud बिल्कुल नहीं। git resetकेवल वर्तमान में चेक-आउट शाखा पर काम करता है।

— अंबर

एक ही परिणाम (तेजी से अग्रेषण) द्वारा प्राप्त किया जाता है git fetch upstream branch-b:branch-b( इस उत्तर से लिया गया )।

— ओलिवर

@ ओलिवर की टिप्पणी पर विस्तार करने के लिए, आप भी कर सकते हैं git fetch <remote> B:A, जहां बी और ए पूरी तरह से अलग शाखाएं हैं, लेकिन बी को तेजी से आगे विलय कर दिया जा सकता है। आप .दूरस्थ एलियास के रूप में उपयोग करके अपने स्थानीय भंडार को "दूरस्थ" के रूप में भी पास कर सकते हैं : git fetch . B:A।

ओपी का सवाल यह स्पष्ट करता है कि मर्ज वास्तव में तेजी से आगे होगा। भले ही, branch -fखतरनाक हो सकता है, जैसा कि आप बताते हैं। तो इसका इस्तेमाल न करें! उपयोग करें fetch origin branchB:branchB, जो सुरक्षित रूप से विफल हो जाएगा यदि मर्ज तेजी से आगे नहीं है।

— बेनेट मैकलेवे

Answer 3

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

मेरे पास एक स्क्रिप्ट है जो मैं इसके लिए उपयोग करता हूं: काम के पेड़ को छूने के बिना तेजी से आगे मर्ज करना (जब तक आप एचईआर में विलय नहीं कर रहे हैं)। यह थोड़ा लंबा है, क्योंकि यह कम से कम थोड़ा मजबूत है - यह सुनिश्चित करने के लिए जांच करता है कि मर्ज एक तेजी से आगे होगा, फिर शाखा की जांच के बिना इसे निष्पादित करता है, लेकिन वही परिणाम उत्पन्न करता है जैसे कि आपके पास था - आप देखते हैं diff --statपरिवर्तनों का सारांश, और रिफ्लग में प्रवेश वास्तव में एक तेज फॉरवर्ड मर्ज की तरह है, इसके बजाय यदि आप उपयोग करते हैं तो आपको "रीसेट" मिलता है branch -f। यदि आप इसे नाम देते हैं git-merge-ffऔर इसे अपनी बिन निर्देशिका में छोड़ देते हैं, तो आप इसे git कमांड के रूप में कॉल कर सकते हैं git merge-ff:।

#!/bin/bash

_usage() {
    echo "Usage: git merge-ff <branch> <committish-to-merge>" 1>&2
    exit 1
}

_merge_ff() {
    branch="$1"
    commit="$2"

    branch_orig_hash="$(git show-ref -s --verify refs/heads/$branch 2> /dev/null)"
    if [ $? -ne 0 ]; then
        echo "Error: unknown branch $branch" 1>&2
        _usage
    fi

    commit_orig_hash="$(git rev-parse --verify $commit 2> /dev/null)"
    if [ $? -ne 0 ]; then
        echo "Error: unknown revision $commit" 1>&2
        _usage
    fi

    if [ "$(git symbolic-ref HEAD)" = "refs/heads/$branch" ]; then
        git merge $quiet --ff-only "$commit"
    else
        if [ "$(git merge-base $branch_orig_hash $commit_orig_hash)" != "$branch_orig_hash" ]; then
            echo "Error: merging $commit into $branch would not be a fast-forward" 1>&2
            exit 1
        fi
        echo "Updating ${branch_orig_hash:0:7}..${commit_orig_hash:0:7}"
        if git update-ref -m "merge $commit: Fast forward" "refs/heads/$branch" "$commit_orig_hash" "$branch_orig_hash"; then
            if [ -z $quiet ]; then
                echo "Fast forward"
                git diff --stat "$branch@{1}" "$branch"
            fi
        else
            echo "Error: fast forward using update-ref failed" 1>&2
        fi
    fi
}

while getopts "q" opt; do
    case $opt in
        q ) quiet="-q";;
        * ) ;;
    esac
done
shift $((OPTIND-1))

case $# in
    2 ) _merge_ff "$1" "$2";;
    * ) _usage
esac

पुनश्च अगर किसी को उस स्क्रिप्ट के साथ कोई समस्या दिखाई देती है, तो कृपया टिप्पणी करें! यह एक लिखने और भूलने की नौकरी थी, लेकिन मैं इसे सुधारने के लिए खुश हूं।

Comments

तुलना के लिए आपको stackoverflow.com/a/5148202/717355 में रुचि हो सकती है

— फिलिप ओकले

@PhilipOakley एक त्वरित नज़र से, कि कोर बिल्कुल मेरी जैसी ही बात करता है। लेकिन मेरा एक एकल जोड़ी शाखाओं के लिए हार्डकोड नहीं है, इसमें बहुत अधिक त्रुटि से निपटने के लिए है, यह गिट-मर्ज के उत्पादन को अनुकरण करता है, और इसका मतलब यह है कि यदि आप वास्तव में शाखा पर हैं तो आप इसे कहते हैं।

— Cascabel

मेरे पास आपकी बिन निर्देशिका में आपका;; मैं बस इसके बारे में भूल गया था और चारों ओर देख रहा था, उस स्क्रिप्ट को देखा और इसने मुझे याद दिलाया! मेरी कॉपी में यह लिंक है और # or git branch -f localbranch remote/remotebranchमुझे स्रोत और विकल्पों की याद दिलाने के लिए है। अपनी टिप्पणी अन्य लिंक a +1 पर दें।

— फिलिप ओकले

+1, "$branch@{u}"अपस्ट्रीम ब्रांच ( kernel.org/pub/software/scm/git/docs/gitrevisions.html से ) को प्राप्त करने के लिए

— कमिट

धन्यवाद! किसी भी मौका आप जवाब में एक सरल उदाहरण-उपयोग फेंक सकते हैं?

— एनएमआर

Answer 4

यह आप तभी कर सकते हैं जब मर्ज तेज़-फ़ॉरवर्ड हो। यदि यह नहीं है, तो git को फ़ाइलों की जाँच करने की आवश्यकता है ताकि यह उन्हें मर्ज कर सके!

इसे केवल तेज़-फॉरवर्ड करने के लिए करें :

git fetch <branch that would be pulled for branchB>
git update-ref -m "merge <commit>: Fast forward" refs/heads/<branch> <commit>

कहां <commit>से लाया गया है, जिस पर आप तेजी से आगे बढ़ना चाहते हैं। यह मूल रूप git branch -fसे शाखा को स्थानांतरित करने के लिए उपयोग करने जैसा है , सिवाय इसके कि यह रिफ्लॉग में भी रिकॉर्ड करता है जैसे कि आपने वास्तव में मर्ज किया था।

कृपया, कृपया, कृपया ऐसा कुछ न करें जो तेजी से आगे न हो, या आप बस अपनी शाखा को अन्य प्रतिबद्ध के लिए रीसेट कर रहे हैं। (जांच करने के लिए, देखें कि क्या git merge-base <branch> <commit>शाखा का SHA1 देता है।)

Comments

अगर यह तेजी से आगे नहीं बढ़ सकता है तो क्या इसे विफल करने का कोई तरीका है?

— गमन

@ आप उपयोग कर सकते हैं git merge-base --is-ancestor <A> <B>। "बी" वह चीज है जिसे "ए" में विलय करने की आवश्यकता है। उदाहरण ए = मास्टर और बी = विकास होगा, यह सुनिश्चित करना कि विकास मास्टर में तेजी से आगे बढ़ना है। नोट: यह 0 के साथ मौजूद है यदि इसकी एफएफ-सक्षम नहीं है, तो 1 के साथ मौजूद है यदि यह है।

— एड्डीमोया

Git-scm में प्रलेखित नहीं है, लेकिन यह kernal.org पर है। kernel.org/pub/software/scm/git/docs/git-merge-base.html

— eddiemoya

यह समझने के लिए कि क्या बात की जा रही है (वास्तव में इसका परीक्षण नहीं किया जाना चाहिए, लेकिन आपको ज्यादातर वहीं मिल जाना चाहिए)। gist.github.com/eddiemoya/ad4285b2d8a6bdabf432 ---- एक साइड नोट के रूप में, मेरे पास इस काम का अधिकांश हिस्सा था, मुझे एक स्क्रिप्ट मिली है जो एफएफ के लिए जांच करती है और यदि आप पहले वांछित शाखा को रिबेट नहीं करते हैं - तो ff विलय - कुछ भी जाँच किए बिना।

— एड्डीमोया

Answer 5

आपके मामले में आप उपयोग कर सकते हैं

git fetch origin branchB:branchB

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

इस फार्म के कुछ और उपयोगी विकल्प भी हैं:

git fetch <remote> <sourceBranch>:<destinationBranch>

ध्यान दें कि <remote> एक स्थानीय भंडार हो सकता है , और <sourceBranch>एक ट्रैकिंग शाखा हो सकती है। तो आप एक स्थानीय शाखा को अपडेट कर सकते हैं, भले ही यह नेटवर्क की पहुंच के बिना चेक आउट न हो ।

वर्तमान में, मेरे अपस्ट्रीम सर्वर की पहुंच धीमी वीपीएन के माध्यम से है, इसलिए मैं समय-समय पर git fetchसभी रीमोट को अपडेट करने के लिए कनेक्ट करता हूं , और फिर डिस्कनेक्ट करता हूं । फिर अगर कहें, तो रिमोट मास्टर बदल गया है, मैं कर सकता हूं

git fetch . remotes/origin/master:master

अपने स्थानीय स्वामी को सुरक्षित रूप से लाने के लिए, भले ही मेरे पास वर्तमान में कोई अन्य शाखा हो। कोई नेटवर्क एक्सेस की आवश्यकता नहीं है।

Answer 6

एक और, बहुत सुंदर तरीके से शाखा को फिर से बनाना है:

git fetch remote
git branch -f localbranch remote/remotebranch

यह स्थानीय पुरानी शाखा को फेंक देता है और एक ही नाम के साथ फिर से बनाता है, इसलिए देखभाल के साथ उपयोग करें ...

Comments

मैंने अभी देखा कि मूल उत्तर में पहले से ही शाखा-एफ का उल्लेख है ... फिर भी, मुझे मूल रूप से वर्णित उपयोग के मामले के लिए रिफ्लॉग में मर्ज होने में एक फायदा नहीं दिखता है।

— कोकेहने

Answer 7

आप रेपो को क्लोन कर सकते हैं और नए रेपो में मर्ज कर सकते हैं। एक ही फाइल सिस्टम पर, यह अधिकांश डेटा कॉपी करने के बजाय हार्डलिंक करेगा। मूल रेपो में परिणामों को खींचकर समाप्त करें।

Answer 8

Git-फॉरवर्ड-मर्ज दर्ज करें :

चेकआउट गंतव्य की आवश्यकता के बिना, git-forward-merge <source> <destination>स्रोत को गंतव्य शाखा में विलय कर देता है।

https://github.com/schuyler1d/git-forward-merge

केवल स्वचालित मर्ज के लिए काम करता है, अगर कोई संघर्ष हो तो आपको नियमित मर्ज का उपयोग करने की आवश्यकता होती है।

Comments

मुझे लगता है कि यह git लाने से बेहतर है <रिमोट> <source>: <डेस्टिनेशन>, क्योंकि फास्ट फॉरवर्ड में मर्ज का ऑपरेशन होता है न कि लाने में और लिखने में आसान होता है। हालांकि बुरी बात यह है कि यह डिफॉल्ट गिट में नहीं है।

— बिनरियन

Answer 9

कई मामलों के लिए (जैसे विलय), आप स्थानीय ट्रैकिंग शाखा को अपडेट किए बिना बस दूरस्थ शाखा का उपयोग कर सकते हैं। ओवरकल की तरह लगता है कि एक संदेश में जोड़ना और इसे जल्दी होने से रोक देगा। इसे पुनर्प्राप्त करना आसान बनाने के लिए, अपने गिट विन्यास में निम्नलिखित जोड़ें

[core]
    logallrefupdates=true

फिर टाइप करें

git reflog show mybranch

अपनी शाखा के लिए हाल के इतिहास को देखने के लिए

Comments

मुझे लगता है कि अनुभाग [core]नहीं होना चाहिए [user]? (और यह एक कार्यक्षेत्र (यानी गैर-नंगे) के साथ

— रिपॉज के

Answer 10

मैंने एक समान उपयोग मामले के लिए एक शेल फ़ंक्शन लिखा था जिसका मैं परियोजनाओं पर प्रतिदिन सामना करता हूं। यह मूल रूप से एक सामान्य शाखा के साथ स्थानीय शाखाओं को रखने के लिए एक शॉर्टकट है जैसे कि पीआर खोलने से पहले विकसित होना, आदि।

भले ही आप checkoutउस बाधा को न समझें, भले ही आप इसका इस्तेमाल न करना चाहें , लेकिन यह पोस्ट करना ।

glmh("जीआईटी पुल और मर्ज यहां") स्वचालित रूप से checkout branchB, pullनवीनतम, फिर से checkout branchA, और होगा merge branchB।

ब्रांच की एक स्थानीय प्रति रखने की आवश्यकता को संबोधित नहीं करता है, लेकिन ब्रांच की जाँच से पहले एक कदम जोड़कर ऐसा करने के लिए आसानी से संशोधित किया जा सकता है। कुछ इस तरह...

git branch ${branchA}-no-branchB ${branchA}

सरल तेज़-फ़ॉरवर्ड मर्ज के लिए, यह प्रतिबद्ध संदेश संकेत के लिए छोड़ देता है।

गैर-फास्ट फ़ॉरवर्ड मर्ज के लिए, यह आपकी शाखा को विवाद समाधान स्थिति में रखता है (आपको हस्तक्षेप करने की आवश्यकता है)।

सेटअप करने के लिए, करने के लिए जोड़ .bashrcया .zshrcआदि,:

glmh() {
    branchB=$1
    [ $# -eq 0 ] && { branchB="develop" }
    branchA="$(git branch | grep '*' | sed 's/* //g')"
    git checkout ${branchB} && git pull
    git checkout ${branchA} && git merge ${branchB} 
}

उपयोग:

# No argument given, will assume "develop"
> glmh

# Pass an argument to pull and merge a specific branch
> glmh your-other-branch

नोट: यह शाखा नाम से परे आर्गन्स को हाथ से बंद करने के लिए पर्याप्त मजबूत नहीं हैgit merge

Answer 11

इसे प्रभावी ढंग से करने का एक और तरीका है:

git fetch
git branch -d branchB
git branch -t branchB origin/branchB

क्योंकि यह एक निचला मामला है -d, यह केवल इसे हटा देगा यदि डेटा अभी भी कहीं मौजूद होगा। यह @ kkoehne के जवाब के समान है, सिवाय इसके कि यह मजबूर न करे। क्योंकि -tयह फिर से रिमोट सेट करेगा।

मुझे ओपी की तुलना में थोड़ी अलग आवश्यकता थी, जो एक पुल अनुरोध को मर्ज करने के बाद एक नई सुविधा शाखा develop(या master) बनाने के लिए थी । यह बिना लाइनर के एक लाइनर में पूरा किया जा सकता है, लेकिन यह स्थानीय developशाखा को अपडेट नहीं करता है । यह सिर्फ एक नई शाखा की जाँच करने और इसे बंद करने की बात है origin/develop:

git checkout -b new-feature origin/develop

Answer 12

बस मैं उपयोग किए गए मास्टर की जांच किए बिना मास्टर को खींचने के लिए

git fetch origin master:master

Answer 13

किसी भी मर्ज, यहां तक ​​कि गैर-फास्ट फॉरवर्ड मर्ज, के बिना करना बिल्कुल संभव है git checkout। worktree@Grego द्वारा जवाब एक अच्छा संकेत है। उस पर विस्तार करने के लिए:

cd local_repo
git worktree add _master_wt master
cd _master_wt
git pull origin master:master
git merge --no-ff -m "merging workbranch" my_work_branch
cd ..
git worktree remove _master_wt

आपने अब masterअपने चेकआउट को स्विच किए बिना स्थानीय कार्य शाखा को स्थानीय शाखा में विलय कर दिया है ।

Answer 14

यदि आप उसी पेड़ को रखना चाहते हैं जिस शाखा को आप मर्ज करना चाहते हैं (यानी एक वास्तविक "मर्ज" नहीं), तो आप इसे इस तरह से कर सकते हैं।

# Check if you can fast-forward
if git merge-base --is-ancestor a b; then
    git update-ref refs/heads/a refs/heads/b
    exit
fi

# Else, create a "merge" commit
commit="$(git commit-tree -p a -p b -m "merge b into a" "$(git show -s --pretty=format:%T b)")"
# And update the branch to point to that commit
git update-ref refs/heads/a "$commit"

Answer 15

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]

आप git worktreeदो शाखाओं को एक साथ खोलने की कोशिश कर सकते हैं , ऐसा लगता है कि यह वही हो सकता है जो आप चाहते हैं, लेकिन कुछ अन्य उत्तरों की तुलना में बहुत अलग हैं जो मैंने यहां देखे हैं।

इस तरह आपके पास एक ही गिट रेपो में ट्रैकिंग करने वाली दो अलग-अलग शाखाएँ हो सकती हैं, इसलिए आपको केवल दोनों कार्य वृक्षों में अपडेट प्राप्त करने के लिए एक बार लाना होगा (बजाय दो बार क्लोन लगाने और प्रत्येक पर गिट पुल खींचने के लिए)

वर्कट्री आपके कोड के लिए एक नई वर्किंग डायरेक्टरी बनाएगी, जहां आपके पास एक अलग ब्रांच हो सकती है, जिसमें जगह-जगह स्वैप करने के बजाय एक साथ ब्रांच हो।

जब आप इसे निकालना चाहते हैं तो आप इसके साथ सफाई कर सकते हैं

git worktree remove [-f] <worktree>