2011-04-14 6 views
8

मैं कुछ कोड का उपयोग कर रहा हूं जिसके लिए कोई एससीएम + का उपयोग नहीं किया जाता है और सभी प्रोजेक्ट फ़ाइलों के रूप में कभी-कभी अपडेट प्राप्त होते हैं, हालांकि उनमें से केवल कुछ ही बदल दिए गए हैं। अब तक मैंने अपने गिट रेपो में अपने बदलाव किए हैं और मैन्युअल git add -p सत्र के साथ इन "अपडेट्स" को हल किया है जो मेरे अपने परिवर्तनों की मात्रा (जो अभी तक प्रकाशित होने के लिए निर्धारित नहीं हैं) के साथ अधिक से अधिक परेशान हो रहा है और सौभाग्य से मैं ऊपर उल्लिखित "पैच" के लिए git commit --author "the others" किया के बाद से, मुझे पता करना चाहते हैं:गिट: एक निश्चित लेखक द्वारा एक अलग शाखा में सभी कामों को कैसे रीबेस करें?

कैसे सब एक लेखक द्वारा की गई करता है सकते हैं एक नई शाखा में विभाजित किया जा?

आदर्श समाधान मेरा हर के बाद "पैच" में दूसरों की शाखा के एक मर्ज को शामिल किया जाएगा (मैं इस मामले में इतिहास को फिर से लिखने, रेपो केवल मेरे द्वारा प्रयोग किया जाता है कोई आपत्ति नहीं है), लेकिन अब के लिए अंत में एक अंतिम विलय पर्याप्त हो सकता है।

git checkout -b other_work <sha1_of_where_to_rebase> 
git log --reverse --author=others --format=%H <sha1_range> | xargs -n 1 git cherry-pick 

आशा इस मदद करता है

+0

मेरे साथ कुछ ही नोट्स जो मैं अगले हफ्ते उत्तर देने का प्रयास करूंगा: 'गिट लॉग - रिवर्स --pretty = प्रारूप: "% एच% एक" HEAD | nl' –

+1

एक 'गिट रेव-लिस्ट' एक स्क्रिप्ट समाधान के लिए अधिक अनुकूलित हो सकता है, जबकि सॉर्ट और सीमित विकल्प प्रदान करते हुए आपको सही काम (यहां, लेखक द्वारा) को अलग करने में मदद मिलेगी। http://www.kernel.org/pub/software/scm/git/docs/git-rev-list.html – VonC

+0

धन्यवाद @ वॉनसी, मैं छुट्टी के बाद इसे देखूंगा –

उत्तर

6

मैं हाल ही में किसी के लिए ऐसा किया महसूस किया आप समझ रहे हैं कि आप क्या कर रहे हैं, लेकिन एक तीसरी पार्टी कोडबेस के साथ आप जिस समस्या का वर्णन करते हैं उसे "विक्रेता ब्र।" कहा जाता है anch "। यहां बताया गया है कि मैं इसे कैसे संभालेगा:

तृतीय पक्ष संस्करण के लिए शाखा बनाएं, उदा। vendor। मुझे लगता है कि आपकी शाखा को master कहा जाता है। जब वे एक नया संस्करण प्रकाशित करते हैं, तो आप निम्न कार्य कर सकते हैं:

git stash # If you have any uncommitted files 
git checkout vendor 
tar -xzvf [new files] # This might be unzip or whatever, rather than tar 
git commit -am "Version xxx from upstream" # Adjust commit message to suit 
git checkout master 
git merge vendor # Bring changes into your branch (you could use rebase here if you prefer to keep all your changes on top of all their changes) 
git stash pop # Restore your uncommitted files 

ps। git add -p के बजाय, मैं git gui का उपयोग करता हूं। मुझे शुरू करने के लिए एक गुई का उपयोग करने पर संदेह था, लेकिन मैं अब git gui और gitk के बिना नहीं रह सकता था (या मैक पर gitx)।

+0

आप --no-merges को जोड़ सकते हैं लॉग कमांड अगर आपके पास –

+0

श्रेणी में कोई भी है, तो स्क्रिप्टिंग के लिए 'गिट लॉग' का उपयोग न करें, – knittl

+0

के बजाय 'गिट रेव-लिस्ट' का उपयोग करें, अंतिम विलय के लिए मैं मूल शाखा को पुनर्स्थापित करके (ठीक है, प्रतिलिपि) 'other_work' पर, फिर इन सभी पुनर्जीवित चीजों को' 'से एक नई शाखा में ले जाएं और अंत में विलय करें। हो सकता है कि मैं इसे अपनी छुट्टियों के बाद एक स्क्रिप्ट में विस्तारित करूं ... –

2

मैं नहीं कर रहा हूँ:


+ हाँ, जेडी आप चापलूसी वहाँ

+0

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

+0

जब मैंने इसका उत्तर दिया, मुझे एहसास नहीं हुआ था कि पिछले साल अप्रैल में यह पिछले महीने अप्रैल में लिखा गया था :-) – rjmunro

संबंधित मुद्दे