मेरे पास दो शाखाएँ हैं masterऔर developmentएक GitHub रिपॉजिटरी में। मैं अपना सारा विकास विकास शाखा में कर रहा हूँ जैसा कि दिखाया गया है।
git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development
अब मैं developmentशाखा के सभी परिवर्तनों को मर्ज करना चाहता हूँ master। मेरा वर्तमान तरीका है:
git checkout master
git merge development
git push -u origin master
कृपया मुझे बताएं कि क्या मैं जिस प्रक्रिया का पालन कर रहा हूं वह सही है।
जवाबों:
मैं आम तौर पर पहले masterमें विलय करना पसंद करता हूं developmentताकि अगर कोई संघर्ष हो, तो मैं developmentशाखा में ही हल कर सकता हूं और मेरी masterसफाई बनी रहती है।
(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won't be any conflicts now)
दो दृष्टिकोणों में बहुत अंतर नहीं है, लेकिन मैंने कभी-कभी देखा है कि मैं शाखा को masterअभी तक विलय नहीं करना चाहता , उन्हें विलय करने के बाद, या यह कि अभी और काम होना बाकी है, इससे पहले कि उनका विलय किया जा सके , इसलिए मैं masterअंतिम सामान तक अछूता छोड़ देता हूं ।
संपादित करें: टिप्पणियों से
यदि आप इस बात पर नज़र रखना चाहते हैं कि किसने और कब विलय किया, तो आप --no-ffऐसा करने के लिए विलय करते समय ध्वज का उपयोग कर सकते हैं । यह आम तौर पर उपयोगी केवल जब विलय है developmentमें masterहै क्योंकि आप मर्ज करने के लिए आवश्यकता हो सकती है, (अंतिम चरण) masterमें development(पहला कदम) अपने कार्यप्रवाह में कई बार बनाने के लिए एक इन के लिए नोड के लिए प्रतिबद्ध बहुत उपयोगी नहीं हो सकता है, और।
git merge --no-ff development
--no-ffइसे ठीक करने के लिए मास्टर को मर्ज करने की एक स्पष्ट आवश्यकता है।
--no-ff। :)
git merge --no-ff developmentसिर्फ @ चुनाव के उपयोग को सही करने के लिए है।
A->B->Cगुरु होने दें , और A->X->Yआपकी देव शाखा है। यदि आप किसी ऐसी फ़ाइल का हिस्सा बदलते हैं, Xजिसमें परिवर्तन के साथ विरोध हो सकता है A, तो यह संघर्ष नहीं होगा, क्योंकि Aइसका पूर्वज है X। खोए हुए परिवर्तनों के बारे में, किसी भी परिवर्तन को पुनर्प्राप्त करने के लिए stackoverflow.com/questions/7147680/… देखें।
व्यक्तिगत रूप से, मेरा दृष्टिकोण आपके समान है, कुछ और शाखाओं के साथ और जब वे मास्टर में वापस जाते हैं तो कुछ स्क्विटिंग करते हैं।
मेरे सहकर्मियों में से एक को शाखाओं को इतना बदलना पसंद नहीं है और विकास शाखा पर कुछ ऐसा ही है, जो विकास शाखा से निष्पादित सभी समान है।
git fetch origin master
git merge master
git push origin development:master
पहली पंक्ति यह सुनिश्चित करती है कि उसके पास कोई अपस्ट्रीम कमिट्स है जो पिछली बार के स्थानीय रिपॉजिटरी को अपडेट करने के बाद से मास्टर करने के लिए बनाया गया है।
दूसरा उन परिवर्तनों (यदि कोई हो) को मास्टर से विकास में खींचता है
तीसरा विकास शाखा (अब पूरी तरह से मास्टर के साथ विलय) को मूल / मास्टर तक बढ़ाता है।
मैं अपने मूल वर्कफ़्लो थोड़ा गलत हो सकता है, लेकिन यह इसका मुख्य सार है।
rebaseअद्यतन devशाखा के साथ merge।
शाखाओं के किसी भी ज्ञान के बिना यहां आए लोगों के लिए नीचे से स्पष्टीकरण।
मूल मास्टर शाखा विकास तर्क है: आप केवल दूसरी शाखाओं पर काम करते हैं और केवल दूसरी शाखाओं को मर्ज करने के लिए मास्टर का उपयोग करते हैं।
आप इस तरह से एक नई शाखा बनाना शुरू करते हैं:
1) आपके स्थानीय डायर में क्लोन रिपोजिटरी (या एक नया रिपॉजिटरी बनाएं):
$ cd /var/www
$ git clone git@bitbucket.org:user_name/repository_name.git
2) एक नई शाखा बनाएं। इसमें आपकी मास्टर ब्रांच रिपॉजिटरी की नवीनतम फाइलें होंगी
$ git branch new_branch
3) अपने वर्तमान गिट शाखा को new_branch में बदलें
$ git checkout new_branch
4) हमेशा की तरह कोडिंग, कमिट करें…
$ git add .
$ git commit -m “Initial commit”
$ git push (pushes commits only to “new_branch”)
5) जब इस शाखा पर नौकरी खत्म हो जाती है, तो "मास्टर" शाखा में विलय करें:
$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldn’t have any commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all “new_branch” commits to both branches - “master” and “new_branch”)
अद्यतन: मैं अत्यधिक परिवर्तन के दृश्य वृक्ष को देखने के लिए और बेहतर सभी तर्क और प्रतिबद्धताओं को देखने के लिए GitKraken का उपयोग करने की सलाह देता हूं।
releaseहमारी शाखा बनाई develop। फिर एक रिलीज नोट फ़ाइल को जोड़ा और प्रतिबद्ध किया। फिर रिलीज को समाप्त किया जो दोनों में वापस विलय हो गया master/develop। लेकिन मेरी मास्टर ब्रांच में केवल नया नोट जारी किया गया था। पिछले विकास के दौरान कोई अन्य फाइल इसमें अपडेट नहीं की गई थी।
यह बहुत अच्छा होगा यदि आप Git Flow वर्कफ़्लो का उपयोग कर सकते हैं । यह विकसित शाखा को आसानी से मास्टर में विलय कर सकता है।
आप जो कुछ करना चाहते हैं, वह यहाँ बताए गए git-flow निर्देश का पालन करें:
कदम:
git flow release start <version_number>git flow release finish <version_number>git pushदूरस्थ मास्टर में परिवर्तन प्रकाशित करने के लिए कमांड चलाएँ ।अधिक जानकारी के लिए पृष्ठ पर जाएँ - http://danielkummer.github.io/git-flow-cheatsheet/
1. //pull the latest changes of current development branch if any
git pull (current development branch)
2. //switch to master branch
git checkout master
3. //pull all the changes if any
git pull
4. //Now merge development into master
git merge development
5. //push the master branch
git push origin master
हां, यह सही है, लेकिन यह एक बहुत ही बुनियादी वर्कफ़्लो की तरह दिखता है, जहां आप एकीकरण के लिए तैयार होने से पहले सिर्फ बफ़र कर रहे हैं। आपको अधिक उन्नत वर्कफ़्लोज़ पर ध्यान देना चाहिए जो गिट समर्थन करता है। आप विषय शाखा दृष्टिकोण को पसंद कर सकते हैं , जो आपको समानांतर में कई विशेषताओं पर काम करने देता है, या स्नातक दृष्टिकोण जो आपके वर्तमान वर्कफ़्लो को थोड़ा बढ़ाता है।
यदि आप मैक या उबंटू पर हैं, तो शाखा के काम करने वाले फ़ोल्डर में जाएं। टर्मिनल में
लगता है कि हरदेवदेव ब्रांचनाम है।
git checkout master
अगर वहाँ अनियंत्रित या uncommitted फ़ाइलें हैं, तो आपको एक त्रुटि मिलेगी और आपको सभी अनट्रैक या uncommitted फ़ाइलों को कमिट या हटाना होगा।
git merge harisdev
git push origin master
शाखा को हटाने के लिए एक अंतिम आदेश।
$ git branch -d harisdev
चरण 1
एक नई "देव" शाखा में बनाएं और स्विच करें, जहां आपकी स्थानीय गिट फाइलें रिमोट के साथ सिंक की जाती हैं, लेकिन "देव" शाखा अभी तक मौजूद नहीं है।
git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch's files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.
चरण 2
"देव" शाखा में अपने बदलाव करें (यदि आप चरण 1 का अनुसरण करते हैं), तो प्रतिबद्ध करें और उन्हें दूरस्थ "देव" शाखा में धकेल दें।
git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.
चरण 3
अपनी "देव" शाखा को "गुरु" में मिलाएं।
git checkout dev # switch to "dev" branch if you're not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn't have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.
ऐसा मैं आमतौर पर करता हूं। सबसे पहले, सुनिश्चित करें कि आप अपने परिवर्तनों को मास्टर में विलय करने के लिए तैयार हैं।
git fetchgit checkout master ।git pullgit merge developmentgit push -u origin masterऔर आप कर रहे हैं।आप लेख में git विलय के बारे में अधिक जानकारी प्राप्त कर सकते हैं ।
1) शाखा विकास पर, निम्नलिखित आदेश का उपयोग कर स्थिति की जाँच करें:
git status
कोई भी अनकम्फर्टेबल कोड नहीं होना चाहिए। यदि ऐसा है, तो विकास शाखा पर अपना कोड डालें:
git add *
git commit -m "My initial commit message"
git push origin Development
2) विकास शाखा पर, दो आदेशों का पालन करें:
git branch -f master HEAD
git push -f origin master
यह आपके विकास शाखा कोड को मास्टर शाखा में धकेल देगा।
-fअनुशंसित नहीं है।
@ शैलेश और @DavidCulp पर आधारित:
(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won't be any conflicts now)
पहला आदेश सुनिश्चित करेगा कि आपके पास रिमोट मास्टर के लिए किए गए सभी अपस्ट्रीम कमिट हैं, जिनके साथ सैलेश की प्रतिक्रिया नहीं होगी।
दूसरा एक मर्ज का प्रदर्शन करेगा और संघर्ष पैदा करेगा जिसे आप तब हल कर सकते हैं।
ऐसा करने के बाद, आप अंततः मास्टर पर स्विच करने के लिए चेकआउट कर सकते हैं।
फिर आप स्थानीय मास्टर पर विकास शाखा का विलय करते हैं। नो-एफएफ ध्वज पूरे मर्ज को ट्रैक करने योग्य बनाने के लिए मास्टर में एक कमिट नोड बनाएगा।
उसके बाद आप अपने मर्ज को कमिट कर सकते हैं और धक्का दे सकते हैं।
यह प्रक्रिया सुनिश्चित करेगी कि विकास से लेकर मास्टर तक के लिए एक मर्ज कमेटी है जिसे लोग देख सकते हैं, फिर अगर वे विकास शाखा को देखते हैं तो वे देख सकते हैं कि आपके विकास के दौरान आपने उस शाखा में किए गए व्यक्तिगत कमिट्स को देखा है।
वैकल्पिक रूप से, आप अपनी मर्ज कमिट को संशोधित कर सकते हैं इससे पहले कि आप इसे धक्का दें, यदि आप विकास शाखा में जो किया गया था उसका सारांश जोड़ना चाहते हैं।
संपादित करें: मेरे मूल उत्तर ने सुझाव दिया git merge masterजो कुछ भी नहीं करता था, यह git merge FETCH_HEADमूल / मास्टर लाने के बाद करना बेहतर है
एक बार जब आप विकास शाखा को 'चेकआउट' कर देते हैं ...
git add .
git commit -m "first commit"
git push origin dev
git merge master
git checkout master
git merge dev
git push origin master
यदि आप जेरिट का उपयोग कर रहे हैं, तो निम्न कमांड पूरी तरह से काम करते हैं।
git checkout master
git merge --no-ff development
आप डिफ़ॉल्ट प्रतिबद्ध संदेश के साथ सहेज सकते हैं। सुनिश्चित करें, परिवर्तन आईडी जनरेट की गई है। आप यह सुनिश्चित करने के लिए निम्न आदेश का उपयोग कर सकते हैं।
git commit --amend
फिर निम्नलिखित कमांड के साथ धक्का दें।
git push origin HEAD:refs/for/refs/heads/master
आप नीचे दिए गए त्रुटि संदेश का सामना कर सकते हैं।
! [remote rejected] HEAD -> refs/for/refs/heads/master (you are not allowed to upload merges)
इसे हल करने के लिए, गेरिट प्रोजेक्ट एडमिन को 'रेफ्स / फॉर / रेफ्स / हेड्स / मास्टर' या 'रिफ्स / फॉर / रिफ्स / हेड्स * * (जिसका भविष्य में सभी ब्रांचों को कवर किया जाएगा) नाम से एक और रेफरेंस बनाना होगा। फिर इस संदर्भ में 'पुश मर्ज कमिट' की अनुमति दें और यदि जीसीआर जमा करना हो तो 'सबमिट' अनुमति दें।
अब, उपरोक्त पुश कमांड को फिर से आज़माएं, और यह काम करना चाहिए।
क्रेडिट:
https://github.com/ReviewAssistant/reviewassistant/wiki/Merging-branches-in-Gerrit
मुझे लगता है कि सबसे आसान समाधान होगा
git checkout master
git remote update
git merge origin/Develop -X theirs
git commit -m commit -m "New release"
git push --recurse-submodules=check --progress "origin" refs/heads/Master
यह उपयोग में आने वाली सभी शाखाओं के इतिहास को भी संरक्षित करता है
1. //push the latest changes of current development branch if any
git push (current development branch)
2. //switch to master branch
git checkout master
3. //pull all the changes if any from (current development branch)
git pull origin (current development branch)
4. //Now merge development into master
git merge development
5. //push the master branch
git push origin master
Error
To https://github.com/rajputankit22/todos-posts.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/rajputankit22/todos-posts.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Then Use
5. //push the master branch forcefully
git push -f origin master
pullबार - बार वापस जाना बेहतर होता है । इसके अलावा, यह स्पष्ट नहीं है कि मौजूदा उत्तरों की तुलना में यह उत्तर किस मूल्य को जोड़ता है।
git pull -uशाखा के लिए अपस्ट्रीम ट्रैकिंग सेट करता है (या यदि सभी शाखाएं एक से अधिक धक्का दे रही हैं)। एक बार जब यह सेट हो जाता है तो ट्रैकिंग बनी रहती है। इसका लगातार उपयोग करने का कोई कारण नहीं है।