क्या git-svn dcommit git में विलय के बाद खतरनाक है?

Question

Git-svn को आज़माने के लिए मेरी प्रेरणा सहज विलय और शाखा है। तब मैंने देखा कि आदमी git-svn (1) कहता है:

जिस शाखा से आप डुबकी लगाने की योजना बना रहे हैं, उस पर गिट-मर्ज या गिट-पुल चलाना अनुशंसित नहीं है। तोड़फोड़ किसी भी उचित या उपयोगी फैशन में मर्ज का प्रतिनिधित्व नहीं करता है; इसलिए तोड़फोड़ का उपयोग करने वाले उपयोगकर्ता आपके द्वारा किए गए किसी भी मर्ज को नहीं देख सकते हैं। इसके अलावा, यदि आप एक git शाखा से विलय या खींचते हैं जो एक SVN शाखा का दर्पण है, तो dcommit गलत शाखा के लिए प्रतिबद्ध हो सकता है।

इसका मतलब यह है कि मैं svn / trunk (या एक शाखा) से एक स्थानीय शाखा नहीं बना सकता, हैक कर सकता हूं, svn / trunk में वापस विलय कर सकता हूं, फिर dcommit? मैं समझता हूं कि svn उपयोगकर्ताओं को वही गड़बड़ दिखाई देगी जो svn में विलय करती है। 1.5.x हमेशा रहा है, लेकिन क्या कोई अन्य कमियां हैं? वह आखिरी वाक्य मुझे भी चिंतित करता है। क्या लोग नियमित रूप से इस प्रकार की चीजें करते हैं?

Comments

यह सिर्फ गलत है: तोड़फोड़ किसी भी उचित या उपयोगी फैशन में विलय का प्रतिनिधित्व नहीं करता है; इसलिए तोड़फोड़ का उपयोग करने वाले उपयोगकर्ता आपके द्वारा किए गए किसी भी मर्ज को नहीं देख सकते हैं। इसके अलावा, यदि आप एक git शाखा से विलय या खींचते हैं जो एक SVN शाखा का दर्पण है, तो dcommit गलत शाखा के लिए प्रतिबद्ध हो सकता है। तोड़फोड़ न केवल गिट मर्ज ट्रैकिंग जानकारी का प्रतिनिधित्व कर सकता है, बल्कि बहुत अधिक बारीक जानकारी भी प्रदान कर सकता है। यह git-svn है जो उचित svn: mergeinfo की रचना करने या एक उचित शाखा के लिए dcommit बनाने में विफल रहता है।

— अलेक्जेंडर कितेव

@AlexanderKitaev: git-svn डॉक्स तब से बदल गए हैं और इसके अलावा एक --mergeinfo=<mergeinfo>विकल्प है जो SVN में मर्ज जानकारी को पास करने में सक्षम हो सकता है। हालांकि यह सुनिश्चित नहीं है कि इसका उपयोग कैसे किया जाना चाहिए।

— Mr_and_Mrs_D

Answer 1

वास्तव में, मुझे --no-ffगिट मर्ज के विकल्प के साथ एक और बेहतर तरीका मिला । यह सब स्क्वैश टेक्निक जिसका मैंने पहले इस्तेमाल किया था, अब इसकी आवश्यकता नहीं है।

मेरा नया वर्कफ़्लो अब इस प्रकार है:

• मैं एक "मास्टर" शाखा केवल शाखा है कि मैं से dcommit और कहा कि क्लोन SVN भंडार है कि है ( -sमान लें कि आपके भंडार में एक मानक SVN लेआउट trunk/, branches/और tags/):

  git svn clone [-s] <svn-url>
  

• मैं एक स्थानीय शाखा "काम" पर काम करता हूं (शाखा "काम" -bबनाता है)

  git checkout -b work
  

• स्थानीय रूप से "काम" शाखा में ( -sअपने प्रतिबद्ध संदेश पर हस्ताक्षर करने के लिए)। अगली कड़ी में, मुझे लगता है कि आपने 3 स्थानीय कमिट किए हैं

  ...
  (work)$> git commit -s -m "msg 1"
  ...
  (work)$> git commit -s -m "msg 2"
  ...
  (work)$> git commit -s -m "msg 3"
  

अब आप SVN सर्वर पर कमिट करना चाहते हैं

• [आखिरकार] उन संशोधनों को रोकें, जिन्हें आप एसवीएन सर्वर पर प्रतिबद्ध नहीं देखना चाहते हैं (अक्सर आपने मुख्य फाइल में कुछ कोड टिप्पणी की थी क्योंकि आप संकलन में तेजी लाना चाहते हैं और किसी दिए गए फीचर पर ध्यान केंद्रित करना चाहते हैं)

  (work)$> git stash
  

• SVN रिपॉजिटरी (SVN सर्वर से अपडेट करने के लिए) के साथ मास्टर ब्रांच को रिबेट करें

  (work)$> git checkout master
  (master)$> git svn rebase
  

• काम की शाखा पर वापस जाएं और मास्टर के साथ रिबेस करें

  (master)$> git checkout work
  (work)$> git rebase master
  

• उदाहरण के लिए, सुनिश्चित करें कि सब कुछ ठीक है

  (work)$> git log --graph --oneline --decorate
  

• अब इस अद्भुत --no-ffविकल्प का उपयोग करके "काम" शाखा से "मास्टर" में सभी तीनों को मिलाने का समय है

  (work)$> git checkout master
  (master)$> git merge --no-ff work
  

• आप लॉग की स्थिति देख सकते हैं:

  (master)$> git log --graph --oneline --decorate
  * 56a779b (work, master) Merge branch 'work'
  |\  
  | * af6f7ae msg 3
  | * 8750643 msg 2
  | * 08464ae msg 1
  |/  
  * 21e20fa (git-svn) last svn commit
  

• अब आप शायद amendअपने एसवीएन दोस्तों के लिए अंतिम प्रतिबद्ध ( ) को संपादित करना चाहते हैं (अन्यथा वे केवल "मर्ज शाखा 'काम' संदेश के साथ एक ही प्रतिबद्ध देखेंगे।"

  (master)$> git commit --amend
  

• अंत में SVN सर्वर पर प्रतिबद्ध है

  (master)$> git svn dcommit
  

• काम पर वापस जाएँ और अंततः अपनी अटकी हुई फ़ाइलों को पुनः प्राप्त करें:

  (master)$> git checkout work
  (work)$> git stash pop
  

Comments

यह वास्तव में काम प्रवाह इस git n00b की तलाश में था। एक बग को ठीक करने के लिए एक स्थानीय शाखा बनाएं, जो कुछ भी करें, फिर इसे SINGLE प्रतिबद्ध के साथ svn तक भेजें। यहां उच्चतम मूल्यांकित उत्तर का उपयोग करते हुए मैंने जो किया वह गड़बड़ कर दिया - त्रुटियों के बिना svn रिबास नहीं कर सका।

— जोहो ब्रागांका

क्या यह वास्तव में git-svn डॉक्स के खिलाफ op चेतावनी में उद्धृत नहीं है? --no-ffविकल्प के साथ मर्ज चलाकर , आप स्पष्ट रूप से एक फास्ट-फॉरवर्ड के बजाय मर्ज कमिट (दो माता-पिता के साथ एक प्रतिबद्ध) बना रहे हैं। यह सुनिश्चित करने के लिए कि svn-ट्रैकिंग शाखा में सभी कमेंट्स सिंगल-पैरेंट कमिट हैं, सभी मर्ज या तो फास्ट-फॉरवर्ड ( --ff-onlyइसके साथ मदद कर सकते हैं) या, यदि ट्रंक आपकी पीठ के पीछे बदल गया है, तो --squash, सही?

— जेमोंस

यह एक बार बंद होने वाली शाखा के लिए काम करता है जिसे आप तुरंत हटा देते हैं, लेकिन यह आपके द्वारा दिए git svn dcommitगए जीआईटी प्रतिबद्ध को फिर से लिखता है। इसका मतलब यह है कि आप अपने अन्य माता-पिता को खो देते हैं, और अब आपके गिट रेपो का कोई रिकॉर्ड नहीं है जिसे आपने कभी उस शाखा में विलय कर दिया है master। यह आपकी कार्यशील निर्देशिका को असंगत स्थिति में भी छोड़ सकता है।

— rescdsk

git merge --no-ff work -m "commit message"एक अतिरिक्त git commit --amendकदम रखने के बजाय उपयोग करें

— टेककुमारा

मेरे लिए मैं "git merge --ff-only work" का उपयोग करना पसंद करूंगा क्योंकि मैं अपने सभी कमिट्स को संरक्षित करना चाहता हूं और केवल पिछले एक को नहीं चाहता हूं

— Moataz Elmasry

Answer 2

स्थानीय शाखाओं का निर्माण निश्चित रूप से git-svn से संभव है। जब तक आप सिर्फ अपने लिए स्थानीय शाखाओं का उपयोग कर रहे हैं, और अपस्ट्रीम svn शाखाओं के बीच विलय करने के लिए गिट का उपयोग करने की कोशिश नहीं कर रहे हैं, आपको ठीक होना चाहिए।

मेरे पास एक "मास्टर" शाखा है जिसका उपयोग मैं svn सर्वर को ट्रैक करने के लिए करता हूं। यह एकमात्र ऐसी शाखा है, जिसे मैं अपने से अलग करता हूं। अगर मैं कुछ काम कर रहा हूं, तो मैं एक विषय शाखा बनाता हूं और उस पर काम करता हूं। जब मैं इसे करना चाहता हूं, तो मैं निम्नलिखित कार्य करता हूं:

1. विषय शाखा के लिए सब कुछ प्रतिबद्ध है
2. git svn rebase (अपने काम और svn के बीच किसी भी विवाद को हल करें)
3. गिट चेकआउट मास्टर
4. git svn rebase (यह अगले कदम को तेजी से आगे मर्ज बनाता है, नीचे हारून की टिप्पणी देखें)
5. git मर्ज topic_branch
6. किसी भी मर्ज संघर्ष को हल करें (इस बिंदु पर कोई भी नहीं होना चाहिए)
7. git svn dcommit

मेरे पास एक और स्थिति है जहां मुझे कुछ स्थानीय परिवर्तनों (डिबगिंग के लिए) को बनाए रखने की आवश्यकता है जिसे कभी भी svn तक नहीं धकेलना चाहिए। उसके लिए, मेरे पास उपरोक्त मास्टर शाखा है, लेकिन एक शाखा भी है जिसे "काम" कहा जाता है जहां मैं सामान्य रूप से काम करता हूं। विषय शाखाओं को काम से निकाल दिया जाता है। जब मैं वहां काम करना चाहता हूं, तो मैं मास्टर चेकआउट करता हूं और काम शाखा से कमिट लेने के लिए चेरी-पिक का उपयोग करता हूं जिसे मैं svn के लिए प्रतिबद्ध करना चाहता हूं। ऐसा इसलिए है क्योंकि मैं तीन स्थानीय बदलाव के लिए प्रतिबद्ध होने से बचना चाहता हूं। फिर, मैं मास्टर ब्रांच से डुबकी लगाता हूं और सब कुछ रिजेक्ट कर देता हूं।

यह चलने योग्य है git svn dcommit -n सुनिश्चित करने के लिए सबसे पहले है कि आप जो करने का इरादा रखते हैं वही करने के बारे में हैं। Git के विपरीत, svn में इतिहास फिर से लिखना कठिन है!

मुझे लगता है कि चेरी-पिक का उपयोग करने की तुलना में उन स्थानीय परिवर्तन को छोड़ते समय विषय शाखा पर परिवर्तन को मर्ज करने का एक बेहतर तरीका होना चाहिए, इसलिए यदि किसी के पास कोई विचार है तो उनका स्वागत किया जाएगा।

Comments

अगर मैं इसे सही ढंग से समझता हूं, तो git में, svn के साथ git का विलय करना ठीक है, लेकिन svn के साथ svn नहीं? इसलिए मैं git में svn / trunk के साथ अपनी svn / शाखा का विलय नहीं कर सकता?

— नॉट एल्डहॉट्स

यदि आप कुछ तुच्छ करना चाहते हैं तो SVN में इतिहास को फिर से लिखना कठिन है। गैर-तुच्छ मामलों में यह व्यावहारिक रूप से असंभव है।

— अरस्तू पगलतज़िस

ग्रेग हेविल के जवाब में बहुत सारे वोट हैं, लेकिन मेरा मानना ​​है कि यह गलत है। यदि यह सिर्फ एक तेज़-फ़ॉरवर्ड मर्ज है, तो topic_branch को मास्टर में विलय करना सुरक्षित है। यदि यह एक मर्ज कमिट की आवश्यकता के लिए एक वास्तविक मर्ज है, तो डोजमिट करते समय मर्ज कमिट खो जाएगा। अगली बार जब आप topic_branch को मास्टर में विलय करने का प्रयास करते हैं, तो git को लगता है कि पहला मर्ज कभी नहीं हुआ है, और सभी नरक ढीले हो जाते हैं। प्रश्न देखें कि git svn dcommit स्थानीय शाखाओं के लिए विलय के इतिहास को क्यों खो देती है?

— हारून

@ ग्रे हेगिल, संपादन स्पष्ट नहीं है। आपने लिखा है कि रिबास "अगले कमिट को तेजी से आगे बढ़ने वाला मर्ज बनाता है।" मुझे नहीं पता कि इसका क्या मतलब है, क्योंकि एक फास्ट-फ़ॉरवर्ड मर्ज में एक कमिट शामिल नहीं है, लेकिन शायद आपका मतलब था "अगले मर्ज को फ़ॉर-फ़ॉर-फ़ॉर मर्ज बनाता है"। लेकिन अगर आपका यही मतलब है, तो यह सही नहीं है। चाहे topic_branch से मास्टर में मर्ज करना एक तेज़ी से अग्रेषित मर्ज है या नहीं यह इस बात पर निर्भर करता है कि शाखा बिंदु के बाद से मास्टर पर कोई कमिट किया गया है या नहीं। जब आप मास्टर को रिबेट करते हैं, जो मास्टर पर नए कमिट बनाता है, इसलिए एक बाद का मर्ज जरूरी है नहीं कि तेजी से आगे बढ़ने वाला मर्ज हो।

— एरोन

@ ऐरॉन: हाँ मुझे नहीं पता कि मैं वहाँ क्या सोच रहा था। मैंने इसे फिर से तय किया है, उम्मीद है कि समझ में आता है। मुसीबतों में से एक यह है कि गिट में चीजों को करने के लिए बहुत सारे तरीके हैं, जो कि कार्यों के एक विशिष्ट अनुक्रम का वर्णन करने के लिए काफी कुछ स्पष्टीकरण लेते हैं ।

— ग्रेग हेवगिल

Answer 3

सरल समाधान: विलय के बाद 'काम' शाखा निकालें

संक्षिप्त उत्तर: आप मर्ज सहित (जैसे एक साधारण वर्कफ़्लो के लिए नीचे देखें) आप git का उपयोग कर सकते हैं। अस्थायी कार्य शाखा को हटाने के लिए ' गिट ब्रांच -d वर्क ' के साथ प्रत्येक ' git मर्ज कार्य ' का पालन करना सुनिश्चित करें ।

पृष्ठभूमि की व्याख्या: मर्ज / डीकमिट समस्या यह है कि जब भी आप एक शाखा को 'git svn dcommit' करते हैं, तो उस शाखा का मर्ज इतिहास 'चपटा' होता है: git इस शाखा में गए सभी मर्ज कार्यों के बारे में भूल जाता है: बस फ़ाइल सामग्री संरक्षित है लेकिन यह तथ्य कि यह सामग्री (आंशिक रूप से) एक विशिष्ट अन्य शाखा से आई है खो गई है। देखें: git svn dcommit स्थानीय शाखाओं के लिए विलय के इतिहास को क्यों खो देती है?

(नोट: इस बारे में बहुत कुछ नहीं है कि git-svn इसके बारे में क्या कर सकता है: svn बस इतना अधिक शक्तिशाली मेरिट मर्ज नहीं समझता है। इसलिए, svn रिपॉजिटरी के अंदर इस मर्ज की जानकारी को किसी भी तरह से प्रस्तुत नहीं किया जा सकता है।)

लेकिन यह पूरी समस्या है। यदि आप 'कार्य' शाखा को 'मास्टर शाखा' में मिलाने के बाद हटाते हैं, तो आपकी गिट रिपॉजिटरी 100% साफ है और बिल्कुल आपकी svn रिपॉजिटरी की तरह दिखती है।

मेरा वर्कफ़्लो: बेशक, मैंने पहली बार रिमोट svn रिपॉजिटरी को एक स्थानीय गिट रिपॉजिटरी में क्लोन किया (इसमें कुछ समय लग सकता है):

$> git svn clone <svn-repository-url> <local-directory>

सभी काम तब "स्थानीय-निर्देशिका" के अंदर होता है। जब भी मुझे सर्वर से अपडेट प्राप्त करने की आवश्यकता होती है (जैसे 'svn अपडेट'), मैं करता हूं:

$> git checkout master
$> git svn rebase

मैं अपने सभी विकास कार्य एक अलग शाखा 'कार्य' में करता हूं जो इस तरह बनाई गई है:

$> git checkout -b work

बेशक, आप अपने काम के लिए जितनी चाहें उतनी शाखाएँ बना सकते हैं और आप के बीच विलय कर सकते हैं और रिबेट कर सकते हैं। अपने सामान्य काम में, मैं बहुत बार करता हूं:

$> git commit -am '-- finished a little piece of work'

अगला चरण (git rebase -i) वैकल्पिक है - यह सिर्फ इतिहास को svn पर संग्रहीत करने से पहले साफ कर रहा है: एक बार जब मैं एक स्थिर मील के पत्थर पर पहुंच गया जिसे मैं दूसरों के साथ साझा करना चाहता हूं, तो मैं इस 'काम' के इतिहास को फिर से लिखता हूं शाखा करें और प्रतिबद्ध संदेशों को साफ करें (अन्य डेवलपर्स को सभी छोटे कदमों और गलतियों को देखने की ज़रूरत नहीं है जो मैंने रास्ते में किए थे --- बस परिणाम)। इसके लिए, मैं करता हूं

$> git log

और अंतिम वचन की श-1 हैश की नकल करें जो कि svn रिपॉजिटरी में लाइव है (जैसा कि git-svn-id द्वारा दर्शाया गया है)। फिर मैं फोन करता हूं

$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

बस हमारे पिछले svn प्रतिबद्ध के श -१ हैश की बजाय मेरा पेस्ट करें। आप विवरण के लिए 'git help rebase' के साथ प्रलेखन पढ़ना चाह सकते हैं। संक्षेप में: यह कमांड सबसे पहले आपके कमिट्स को प्रस्तुत करने वाला एक एडिटर खोलता है ---- बस उन सभी कमिट्स के लिए 'पिक' को 'स्क्वैश' में बदलें, जिन्हें आप पिछले कमिट्स के साथ स्क्वैश करना चाहते हैं। बेशक, पहली पंक्ति को 'पिक' के रूप में रहना चाहिए। इस तरह, आप एक या एक से अधिक सार्थक इकाइयों में अपने बहुत से कमिट्स को संघनित कर सकते हैं। सहेजें और संपादक से बाहर निकलें। आपको एक अन्य संपादक मिलेगा जो आपको प्रतिबद्ध लॉग संदेशों को फिर से लिखने के लिए कहेगा।

संक्षेप में: 'कोड हैकिंग' समाप्त करने के बाद, मैं अपनी 'काम' शाखा की मालिश करता हूं, जब तक कि यह नहीं दिखता कि मैं इसे अन्य प्रोग्रामर को कैसे प्रस्तुत करना चाहता हूं (या मैं इतिहास ब्राउज़ करते समय कुछ हफ्तों में काम कैसे देखना चाहता हूं) ।

Svn रिपॉजिटरी में बदलावों को आगे बढ़ाने के लिए, मैं यह करता हूं:

$> git checkout master
$> git svn rebase

अब हम पुरानी 'मास्टर' शाखा में वापस आ गए हैं जो सभी परिवर्तनों के साथ अद्यतन हुई है जो svn रिपॉजिटरी में माध्य समय में हुई है (आपके नए परिवर्तन 'कार्य शाखा' में छिपे हुए हैं)।

यदि ऐसे परिवर्तन हैं जो आपके नए 'कार्य' परिवर्तनों से टकरा सकते हैं, तो आपको अपने नए काम को आगे बढ़ाने से पहले उन्हें स्थानीय रूप से हल करना होगा (नीचे विवरण देखें)। फिर, हम svn में अपने बदलावों को आगे बढ़ा सकते हैं:

$> git checkout master
$> git merge work        # (1) merge your 'work' into 'master'
$> git branch -d work    # (2) remove the work branch immediately after merging
$> git svn dcommit       # (3) push your changes to the svn repository

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

नोट 2: बीच-बीच में अपनी शाखा को 'गिट ब्रांच -d वर्क' से हटाना सुनिश्चित करें मर्जिंग और डीकमिट के : यदि आप डीकमिट के बाद शाखा को हटाने की कोशिश करते हैं, तो आपको एक त्रुटि संदेश मिलता है: जब आप 'git svn dcommit' करते हैं, तो यह भूल जाते हैं कि आपकी शाखा को 'मास्टर' के साथ मिला दिया गया है। आपको इसे 'गिट ब्रांच -D वर्क' से हटाना होगा जो सेफ्टी चेक नहीं करता है।

अब, मैं तुरंत 'मास्टर' शाखा पर गलती से हैकिंग से बचने के लिए एक नई 'कार्य' शाखा बनाता हूं:

$> git checkout -b work
$> git branch            # show my branches:
  master
* work

Svn पर बदलाव के साथ अपने 'काम' को एकीकृत करना: यहाँ मैं क्या करता हूँ जब 'git svn rebase' से पता चलता है कि दूसरों ने svn रिपॉजिटरी को तब बदल दिया जब मैं अपनी 'कार्य' शाखा में काम कर रहा था:

$> git checkout master
$> git svn rebase              # 'svn pull' changes
$> git checkout work           # go to my work
$> git checkout -b integration # make a copy of the branch
$> git merge master            # integrate my changes with theirs
$> ... check/fix/debug ...
$> ... rewrite history with rebase -i if needed

$> git checkout master         # try again to push my changes
$> git svn rebase              # hopefully no further changes to merge
$> git merge integration       # (1) merge your work with theirs
$> git branch -d work          # (2) remove branches that are merged
$> git branch -d integration   # (2) remove branches that are merged
$> git svn dcommit             # (3) push your changes to the svn repository

अधिक शक्तिशाली समाधान मौजूद हैं: प्रस्तुत वर्कफ़्लो सरलीकृत है: यह 'अपडेट / हैक / डॉकमिट' के प्रत्येक दौर के भीतर केवल गिट की शक्तियों का उपयोग करता है --- लेकिन लंबी अवधि के प्रोजेक्ट इतिहास को केवल एसएन रिपॉजिटरी के रूप में रैखिक छोड़ देता है। यह ठीक है अगर आप बस एक विरासत एसवीएन परियोजना में छोटे पहले चरणों में गिट मर्ज का उपयोग शुरू करना चाहते हैं।

जब आप git मर्जिंग के बारे में अधिक परिचित हो जाते हैं, तो अन्य वर्कफ़्लोज़ का पता लगाने के लिए स्वतंत्र महसूस करें: यदि आप जानते हैं कि आप क्या कर रहे हैं, तो आप svn मर्ज के साथ git मर्ज को मिला सकते हैं ( svit मर्ज में मदद करने के लिए git-svn (या समान) का उपयोग करना? )

Comments

यह अनावश्यक रूप से जटिल लगता है। मैंने लोगों को करते हुए सुना है git merge --squash work, ऐसा क्यों नहीं करते? यदि आप एक से अधिक 'पिक' बना रहे हैं, तो आप शाखा में स्क्वैश कमिट करते हुए देख सकते हैं (जैसे कि आपके पास 8 कमिट हैं और आप 4 में से प्रत्येक को 1 में बदल रहे हैं, और 2 कॉम को मास्टर में विलय कर रहे हैं)। अपनी 'कार्य' शाखा को अपडेट करते समय, मैं करता हूं rebase, यह मेरी शाखा के लिए एक और शाखा बनाने और मर्ज करने की तुलना में सरल है ...

— void.pointer

Answer 4

शीर्ष पर ग्रेग हेविल का जवाब सुरक्षित नहीं है! यदि दो "गिट svn रिबास" के बीच ट्रंक पर कोई नया कमिट दिखाई दिया, तो मर्ज तेजी से आगे नहीं होगा।

इसे "--ff-only" ध्वज का उपयोग करके git-merge में सुनिश्चित किया जा सकता है, लेकिन मैं आमतौर पर शाखा में "git svn rebase" नहीं चलाता, केवल उस पर "git rebase master" (यह मानते हुए कि यह केवल एक स्थानीय है डाली)। फिर बाद में एक "गिट मर्ज thebranch" तेजी से आगे बढ़ने की गारंटी है।

Answer 5

Git मर्ज --squash का उपयोग करने के लिए git में svn शाखाओं को मर्ज करने का एक सुरक्षित तरीका है। यह एक एकल प्रतिबद्धता बनाएगा और आपके लिए एक संदेश जोड़ने के लिए बंद हो जाएगा।

मान लीजिए कि आपके पास एक विषय है svn शाखा, जिसे svn- शाखा कहा जाता है।

git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch

इस बिंदु पर आपके पास svn- शाखा से सभी परिवर्तन हैं जो सूचकांक में प्रतीक्षा कर रहे हैं

git commit

Comments

जैसा कि दूसरों ने बताया है, हालांकि, यह कमिट्स की ग्रैन्युलैरिटी को खो देता है।

— क्ज़कई

@Tchalvak: कभी-कभी आप बस यही चाहते हैं। मैं अक्सर एक सुविधा शाखा अला में "पिछली प्रतिबद्ध से निश्चित गड़बड़" करता हूं और ये मृत समाप्त होते हैं मैं एक अच्छी प्रतिष्ठा के कारण छिपाना पसंद करता

— हूं

हाँ, हालाँकि मैं समझता हूँ कि जब भी आप स्क्वैश करते हैं, तब से आप टहलना छोड़ देते हैं, आप बाद में अलग-अलग आवागमन करने की क्षमता भी खो देते हैं। बस मानकों के विभिन्न विकल्पों की बात है।

— क्ज़कई १५'११ को z:59

@schoetbi हाँ, आपको कभी-कभी प्रकाशन से पहले गन्दा इतिहास साफ़ करना होगा। यह वह जगह है जहाँ 'git rebase -i <trunk>' एक बड़ी मदद है: आप / reorder / हटा सकते हैं और यहाँ तक कि विभाजित भी कर सकते हैं!

— Inger

Answer 6

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

git rebase master topic

जो बाद में आपके द्वारा तैयार की गई मास्टर ब्रांच पर आपके कॉम्पटिशन को आपके सामने खेलने के लिए भेज देगा