हमारा कोड गीथब पर है और हम कोड की समीक्षा के लिए पुल अनुरोधों का उपयोग करते हैं। समीक्षा के परिणामस्वरूप एक प्रतिबद्धता को वापस या बदला जा सकता है। यह प्रतिबद्ध इतिहास को अव्यवस्थित कर सकता है। rebase कमांड को हतोत्साहित किया गया है क्योंकि काम पहले ही "सार्वजनिक रूप से उपलब्ध" हैं।गिटहब पुल अनुरोध कोड समीक्षा के बाद एक साफ इतिहास कैसे रखें?
यदि आप इसी तरह से कोड समीक्षा करते हैं: आप इससे कैसे निपटते हैं? आप अपना इतिहास कैसे साफ रखते हैं?
गैर-मास्टर (रखरखाव *, अगली) शाखाओं को रीबेज करना ठीक है, यहां तक कि वे प्रकाशित होते हैं। समीक्षा के लिए नई सामग्री प्रकाशित करने के लिए बस विषय शाखाओं का उपयोग करें। फिर उन्हें मास्टर में विलय करने के बाद या पुल अनुरोध अस्वीकार करने के बाद किसी भी मामले में उन्हें हटा दें। man gitworkflows
मैं सुझाव देता हूं कि प्रतिबद्धता इतिहास को आसानी से प्राप्त किया जाए।
ध्यान रखें कि जब आप इतिहास देखते हैं, तो आप आमतौर पर कुछ मौजूदा प्रतिबद्धताओं के पूर्वजों को देख रहे हैं। यदि आपकी कोड समीक्षा प्रक्रिया कोड के लिए मृत-अंत शाखाएं बनाती है जो किसी भिन्न प्रतिबद्धता के रूप में अस्वीकार या पुनः सबमिट की जाती हैं, तो वे ऐसे किसी भी वंश में नहीं होंगे, और आमतौर पर नहीं देखी जाएंगी।
यहाँ इस का एक घना लेकिन पूरा उदाहरण है, इतिहास दर्शक के रूप में git log का उपयोग कर:
$ git init example
Initialized empty Git repository in /private/tmp/example/.git/
$ cd example/
$ date >date
$ git add date
$ git commit -am base
[master (root-commit) 5108762] base
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 date
$ date >date
$ git commit -am bad
[master 440c3b6] bad
1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 440c3b61b279e8b7cd5f5f656984b63ba18e518b
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:48 2012 +0000
bad
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:28 2012 +0000
base
$ git branch postreview 5108762ba7011464fe3c57cf762d0d18f337f68c
$ git checkout postreview
Switched to branch 'postreview'
$ date >date
$ git commit -am good
[postreview 42e5257] good
1 files changed, 1 insertions(+), 1 deletions(-)
$ git log
commit 42e5257addf73b516676d24e7092b0e4768d3564
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:17:30 2012 +0000
good
commit 5108762ba7011464fe3c57cf762d0d18f337f68c
Author: Tom Anderson <[email protected]>
Date: Sat Mar 10 09:15:28 2012 +0000
base
हालांकि बुरा प्रतिबद्ध भंडार में है, यह नहीं ऊपर Git लॉग उत्पादन में दिखाता है । इस मामले में, मैंने अपनी पोस्ट-समीक्षा कार्य करने के लिए एक नई शाखा बनाई है, लेकिन व्यावहारिक रूप से, आप शायद नए काम के लिए मास्टर को स्थानांतरित करना चाहते हैं, जिससे पुराने कार्य को मृत शाखा में छोड़ दिया जा सके।
यदि मुझे आपका उदाहरण सही लगता है, तो यह केवल अंतिम प्रतिबद्धता के लिए काम करता है। या? अन्यथा मुझे शायद 'पोस्टरव्यू' में चुनने की ज़रूरत है? –
मैं सोच रहा था कि समीक्षा के तहत कोड लिखना शुरू करने से पहले आप अपनी नई शाखा शुरू कर देंगे, संभावित रूप से कई लोग वापस आते हैं, इसलिए हाँ, आप नई शाखा में जो कुछ भी रखना चाहते हैं उसे चुन लेंगे। यह मूल रूप से एक rebase के समान है, लेकिन कुछ संपादन के साथ रास्ते में काम करता है, और पुराने कामों को हटा नहीं है। वास्तव में, आप इसे एक रिबेस के रूप में करने में सक्षम हो सकते हैं। –
मैंने दोनों दृष्टिकोणों की कोशिश की और यह मेरे लिए बहुत अच्छा काम करता है। धन्यवाद! –