🏂🏿 ⛰️ 🔼 Git rebase "बटन पर" ❤️ 🎃 🎒

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

क्रियाएं मैन्युअल रूप से की जाती हैं, जिसमें एकाग्रता और सटीकता की आवश्यकता होती है;
कठिन समय सीमा।

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

गित प्रवाह

फिलहाल, Git सबसे सामान्य संस्करण नियंत्रण प्रणालियों में से एक है, और हम इसे सफलतापूर्वक Badoo में उपयोग करते हैं।
गिट के साथ काम करने की प्रक्रिया काफी सरल है।

हमारे मॉडल की ख़ासियत यह है कि हम प्रत्येक कार्य को एक अलग शाखा में विकसित और परीक्षण करते हैं। इस शाखा के नाम में JIRA में एक टिकट नंबर और कार्य का मुफ्त विवरण शामिल है। उदाहरण के लिए:

BFG-9000_All_developers_should_be_given_a_years_holiday_ (भुगतान किया गया)

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

एक रिलीज का निर्माण ऑटोमेशन टूल का उपयोग करके रिलीज शाखा में कार्यों को मर्ज करके किया जाता है। हमारे पास एक मास्टर शाखा भी है, जो उत्पादन सर्वर की एक प्रति है। रिलीज के एकीकरण परीक्षण चरण और प्रत्येक व्यक्तिगत कार्य के बाद, कोड को उत्पादन सर्वर पर भेजा जाता है और मास्टर शाखा में विलय कर दिया जाता है।
जब एक रिलीज का मंचन पर्यावरण पर परीक्षण किया जाता है और एक कार्य में एक त्रुटि का पता लगाया जाता है, और इसे ठीक करने का कोई समय नहीं होता है, तो हम केवल गिट रिबेस का उपयोग करके इस कार्य को रिलीज से हटा देते हैं।

नोट। हम रिलीज़ शाखा में git रिवर्ट फ़ंक्शन का उपयोग नहीं करते हैं, क्योंकि यदि आप git रिवर्ट का उपयोग करके रिलीज़ ब्रांच से कार्य हटाते हैं और रिलीज़ शाखा मास्टर में विलीन हो जाती है, तब से डेवलपर उस शाखा में ताज़ा कोड खींचता है जिसमें त्रुटि हुई, तो उसे वापस करना होगा अपने परिवर्तनों को वापस करने के लिए वापस लौटें।

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

समस्या का बयान

विचार करें कि प्रक्रिया को स्वचालित करने के लिए क्या उपयोग किया जा सकता है:
1. जिस रिलीज शाखा से हम टिकट वापस करने जा रहे हैं, उसमें दो श्रेणियां हैं:

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

2. बिल्ट-इन git रिबास टूल, जो सुविधाजनक विज़ुअलाइज़ेशन के कारण अंतःक्रियात्मक रूप से उपयोग किया जाता है।

आपके सामने आने वाली समस्याएं :

1. गिट रीबेस ऑपरेशन के दौरान, ब्रांच के सभी कम्बाइंड इंटरलीव्ड होते हैं, जो कि पीछे की तरफ से शुरू होते हैं।
2. यदि विलय के दौरान एक मर्ज संघर्ष को मैन्युअल रूप से हल किया गया था, तो Git इस संघर्ष का समाधान मेमोरी में नहीं बचाएगा, इसलिए, जब गिट रीबेस ऑपरेशन करते हैं, तो मैनुअल मोड में मर्ज टकराव को फिर से ठीक करना आवश्यक होगा।
3. एक विशेष एल्गोरिथ्म में संघर्ष दो प्रकारों में विभाजित हैं:

सरल - इस तरह के टकराव इस तथ्य के कारण उत्पन्न होते हैं कि संस्करण नियंत्रण प्रणाली की कार्यक्षमता पहले विलय किए गए संघर्षों को याद रखने की अनुमति नहीं देती है;
जटिल - इस तथ्य के कारण उत्पन्न होता है कि कोड एक विशिष्ट लाइन (फाइल) में तय किया गया था न केवल प्रतिबद्ध में, जिसे शाखा से हटा दिया जाता है, बल्कि बाद के कमिट्स में भी होता है जो गिट रिबेस प्रक्रिया के दौरान रुक-रुक कर होते हैं। उसी समय, डेवलपर ने इस संघर्ष को मैन्युअल रूप से ठीक किया और रिलीज शाखा पर धकेल दिया।

Git में एक दिलचस्प git rerere फंक्शन है जो मर्ज के साथ संघर्षों को हल करने को याद करता है। यह स्वचालित मोड में चालू होता है, लेकिन दुर्भाग्य से, इस मामले में हमारी मदद नहीं कर सकता है। यह फ़ंक्शन केवल तब काम करता है जब दो लंबे समय तक रहने वाली शाखाएं होती हैं जो लगातार विलय करती हैं - ये संघर्ष बिना समस्याओं के याद रखता है।
हमारे पास केवल एक शाखा है, और अगर -फोर्स फ़ंक्शन का उपयोग नहीं किया जाता है, तो रिपॉजिटरी में गिट पुश परिवर्तन करते हैं, तो प्रत्येक गिट रिबेस के बाद आपको एक नया परिवर्तन ट्रंक के साथ एक नई शाखा बनाना होगा। उदाहरण के लिए, हम पोस्टफ़िक्स _r1, r2, r3 ... प्रत्येक सफल गिट रीबेस ऑपरेशन के बाद लिखते हैं और रिपॉजिटरी को नई रिलीज़ शाखा का गिट पुश करते हैं। इस प्रकार, संघर्ष समाधान का इतिहास संरक्षित नहीं है।

आखिर में हम क्या पाना चाहते हैं ?

हमारे बगट्रैकर में एक विशिष्ट बटन दबाकर:
1. कार्य को स्वचालित रूप से रिलीज़ से हटा दिया जाएगा।
2. एक नई रिलीज शाखा बनाई जाएगी।
3. कार्य की स्थिति को फिर से खोलने के लिए स्थानांतरित कर दिया जाएगा।
4. कार्य को रिलीज से हटाने की प्रक्रिया में, सभी सरल मर्ज संघर्ष हल हो जाएंगे।

दुर्भाग्य से, किसी भी योजना में जटिल मर्ज संघर्षों को हल करना असंभव है, इसलिए यदि ऐसा कोई संघर्ष होता है, तो हम डेवलपर और रिलीज इंजीनियर को सूचित करेंगे।

मुख्य कार्य

1. हमारी स्क्रिप्ट इंटरएक्टिव रिबास का उपयोग करती है और कार्य की संख्या के साथ रिलीज़ ब्रांच में आने वाले कैच को वापस ले जाती है।
2. जब आवश्यक कमियां मिल जाती हैं, तो यह उन फ़ाइलों के नाम को याद करते हुए उन्हें हटा देता है।
3. अगला, यह सभी कमिट्स को इंटरमिट करता है, पिछली शाखा से शुरू होता है जिसे हमने ट्रंक में हटा दिया था।
4. यदि कोई विरोधाभास होता है, तो यह उन फ़ाइलों की जाँच करता है जो इस संघर्ष में शामिल हैं। यदि ये फाइलें दूरस्थ कमिट की फाइलों के साथ मेल खाती हैं, तो हम डेवलपर को सूचित करते हैं और इंजीनियर को सूचित करते हैं कि एक जटिल संघर्ष उत्पन्न हुआ है, जिसे मैन्युअल रूप से हल किया जाना चाहिए।
5. यदि फाइलें मेल नहीं खाती हैं, लेकिन संघर्ष उत्पन्न हुआ, तो यह एक साधारण संघर्ष है। फिर हम कमिट से फाइल कोड लेते हैं, जिसमें डेवलपर ने पहले से ही इस विरोधाभास को मूल रिपॉजिटरी से हल कर लिया है।

तो "शाखा के प्रमुख को चलाएं।"

एक कठिन संघर्ष में हम खुद को जिस संभावना से देखेंगे, वह नगण्य है, यानी इस प्रक्रिया के 99% निष्पादन अपने आप हो जाएंगे।

कार्यान्वयन

आइए अब एक चरण-दर-चरण देखें कि हमारी स्क्रिप्ट क्या करेगी (उदाहरण केवल स्वचालित रीबेस का उपयोग करता है और आप स्क्रिप्ट को केवल कंसोल में उपयोग कर सकते हैं):
1. हम भंडार को साफ करते हैं और रिलीज शाखा के नवीनतम संस्करण को खींचते हैं।
2. हमें उस शाखा में मर्ज के साथ ट्रंक में ऊपरी प्रतिबद्धता मिलती है जिसे हम वापस रोल करना चाहते हैं।
एक। यदि कोई प्रतिबद्ध नहीं है, तो हम सूचित करते हैं कि वापस रोल करने के लिए कुछ भी नहीं है।
3. हम एक स्क्रिप्ट एडिटर बनाते हैं जो केवल ट्रंक से मर्ज के कमिट को हटाता है, इस प्रकार उन्हें इतिहास से हटा देता है।
4. स्क्रिप्ट एडिटर (EDITOR) को सेट करें, जिसे हमने स्क्रिप्ट के रिवर्ट के माहौल में पिछले चरण में बनाया था।
5. रिलीज के लिए गिट रिबेस -आईपी चलाएं। त्रुटि कोड की जाँच करना।
एक। अगर 0, तो सब कुछ ठीक हो गया। डिलीट किए जाने वाले टास्क ब्रांच के संभावित पिछले कमिट्स को खोजने के लिए चरण 2 पर जाएं।
b। यदि 0 नहीं है, तो एक संघर्ष उत्पन्न हुआ है। हम हल करने की कोशिश करते हैं:
मैं। हमें उस कमिट का हैश याद है जो थोपा नहीं जा सकता था।
यह फ़ाइल में निहित है .it / rebase-merge / रोका-शा
ii। हम यह पता लगाने के लिए रिबेस कमांड के आउटपुट को पार्स करते हैं कि क्या गलत है।
1. यदि Git हमें "CONFLICT (सामग्री): मर्ज संघर्ष" बताता है, तो हम इस फाइल की तुलना डिलीट किए गए पिछले संशोधन से करते हैं, और यदि यह अलग नहीं होती है (फाइल कमिट में नहीं बदली गई है), तो हम बस इस फाइल को बिल्ड ब्रांच के प्रमुख और करता है। यदि यह अलग है, तो बाहर निकलें, और डेवलपर मैन्युअल रूप से संघर्ष को हल करता है।
2. अगर Git कहता है "घातक: कमिट एक मर्ज है, लेकिन कोई विकल्प नहीं दिया गया है", तो बस --continue ध्वज के साथ फिर से दोहराएं। मर्ज कमेटी को छोड़ दिया जाएगा, लेकिन बदलाव नहीं होंगे। आमतौर पर यह मास्टर शाखा के साथ होता है, लेकिन यह पहले से ही शाखा के प्रमुख में खींच लिया गया था और इस विलय की जरूरत नहीं है।
3. अगर Git कहता है "त्रुटि: लागू नहीं हो सका ... जब आपने" git rebase --continue "चलाने वाली इस समस्या को हल कर लिया है, तो फ़ाइलों की सूची प्राप्त करने के लिए git स्टेटस करें। यदि कम से कम एक स्टेटस फ़ाइल उस कमिट में है जिसे हम वापस ला रहे हैं, तो हम कमिट (रिबेस -स्काइप) को छोड़ देते हैं, जिसे हमने चरण ५.६ में याद किया है, इस बारे में लॉग को लिख रहे हैं ताकि रिलीज इंजीनियर इसे देख सके और यह निर्णय ले सके कि किसी की जरूरत है प्रतिबद्ध या नहीं।
4. यदि उपरोक्त में से कोई भी नहीं होता है, तो स्क्रिप्ट से बाहर निकलें और कहें कि कुछ अक्षम्य हो गया है।
6. चरण 5 को तब तक दोहराएं जब तक कि बाहर निकलने का कोड 0 आउटपुट पर दिखाई न दे, या लूपिंग त्रुटियों से बचने के लिए लूप में काउंटर> 5 नहीं है।

स्क्रिप्ट कोड

/** *     ,     . *   . */ function runBuildRevert($args) { if (count($args) != 2) { $this->commandUsage("<build-name> <ticket-key>"); return $this->error("Unknown build!");; } $build_name = array_shift($args); $ticket_key = array_shift($args); $build = $this->Deploy->buildForNameOrBranch($build_name); if (!$build) return false; if ($this->directSystem("git reset --hard && git clean -fdx")) { return $this->error("Can't clean directory!"); } if ($this->directSystem("git fetch")) { return $this->error("Can't fetch from origin!"); } if ($this->directSystem("git checkout " . $build['branch_name'])) { return $this->error("Can't checkout build branch!"); } if ($this->directSystem("git pull origin " . $build['branch_name'])) { return $this->error("Can't pull build branch!"); } $commit = $this->_getTopBranchToBuildMergeCommit($build['branch_name'], $ticket_key); $in_stream_count = 0; while (!empty($commit)) { $in_stream_count += 1; if ($in_stream_count >= 5) return $this->error("Seems rebase went to infinite loop!"); $editor = $this->_generateEditor($build['branch_name'], $ticket_key); $output = ''; $code = 0; $this->exec( 'git rebase -ip ' . $commit . '^^', $output, $code, false ); while ($code) { $output = implode("\n", $output); $conflicts_result = $this->_resolveRevertConflicts($output, $build['branch_name'], $commit); if (self::FLAG_REBASE_STOP !== $conflicts_result) { $command = '--continue'; if (self::FLAG_REBASE_SKIP === $conflicts_result) { $command = '--skip'; } $output = ''; $code = 0; $this->exec( 'git rebase ' . $command, $output, $code, false ); } else { unlink($editor); return $this->error("Giving up, can't resolve conflicts! Do it manually.. Output was:\n" . var_export($output, 1)); } } unlink($editor); $commit = $this->_getTopBranchToBuildMergeCommit($build['branch_name'], $ticket_key); } if (empty($in_stream_count)) return $this->error("Can't find ticket merge in branchdiff with master!"); return true; } protected function _resolveRevertConflicts($output, $build_branch, $commit) { $res = self::FLAG_REBASE_STOP; $stopped_sha = trim(file_get_contents('.git/rebase-merge/stopped-sha')); if (preg_match_all('/^CONFLICT\s\(content\)\:\sMerge\sconflict\sin\s(.*)$/m', $output, $m)) { $conflicting_files = $m[1]; foreach ($conflicting_files as $file) { $output = ''; $this->exec( 'git diff ' . $commit . '..' . $commit . '^ -- ' . $file, $output ); if (empty($output)) { $this->exec('git show ' . $build_branch . ':' . $file . ' > ' . $file); $this->exec('git add ' . $file); $res = self::FLAG_REBASE_CONTINUE; } else { return $this->error("Can't resolve conflict, because file was changed in reverting branch!"); } } } elseif (preg_match('/fatal\:\sCommit\s' . $stopped_sha . '\sis\sa\smerge\sbut\sno\s\-m\soption\swas\sgiven/m', $output)) { $res = self::FLAG_REBASE_CONTINUE; } elseif (preg_match('/error\:\scould\snot\sapply.*When\syou\shave\sresolved\sthis\sproblem\srun\s"git\srebase\s\-\-continue"/sm', $output)) { $files_status = ''; $this->exec( 'git status -s|awk \'{print $2;}\'', $files_status ); foreach ($files_status as $file) { $diff_in_reverting = ''; $this->exec( 'git diff ' . $commit . '..' . $commit . '^ -- ' . $file, $diff_in_reverting ); if (!empty($diff_in_reverting)) { $this->warning("Skipping commit " . $stopped_sha . " because it touches files we are reverting!"); $res = self::FLAG_REBASE_SKIP; break; } } } return $res; } protected function _getTopBranchToBuildMergeCommit($build_branch, $ticket) { $commit = ''; $this->exec( 'git log ' . $build_branch . ' ^origin/master --merges --grep ' . $ticket . ' -1 --pretty=format:%H', $commit ); return array_shift($commit); } protected function _generateEditor($build_branch, $ticket, array $exclude_commits = array()) { $filename = PHPWEB_PATH_TEMPORARY . uniqid($build_branch) . '.php'; $content = <<<'CODE' #!/local/php5/bin/php <?php $build = '%s'; $ticket = '%s'; $commits = %s; $file = $_SERVER['argv'][1]; if (!empty($file)) { $content = file_get_contents($file); $build = preg_replace('/_r\d+$/', '', $build); $new = preg_replace('/^.*Merge.*branch.*' . $ticket . '.*into\s' . $build . '.*$/m', '', $content); foreach ($commits as $exclude) { $new = preg_replace('/^.*' . preg_quote($exclude, '/') . '$/m', '', $new); } file_put_contents($file, $new); } CODE; $content = sprintf($content, $build_branch, $ticket, var_export($exclude_commits, 1)); file_put_contents($filename, $content); $this->exec('chmod +x ' . $filename); putenv("EDITOR=" . $filename); return $filename; }

निष्कर्ष

नतीजतन, हमें एक स्क्रिप्ट मिली जो स्वचालित मोड में रिलीज़ शाखा से एक कार्य को हटा देती है। हमने रिलीज को बनाने और परीक्षण की प्रक्रिया में समय बचाया, जबकि मानव कारक को लगभग पूरी तरह से समाप्त कर दिया।
बेशक, हमारी स्क्रिप्ट सभी Git उपयोगकर्ताओं के लिए उपयुक्त नहीं है। कुछ मामलों में, गिट रिवर्ट का उपयोग करना आसान है, लेकिन इसमें शामिल नहीं होना बेहतर है (रिवर्ट के लिए वापस लौटना ...)। हम आशा करते हैं कि सबसे सरल git rebase ऑपरेशन आपके लिए अधिक समझने योग्य नहीं है, लेकिन हमारी स्क्रिप्ट उन लोगों के लिए भी उपयोगी है, जो लगातार विकास और एक रिलीज बनाने की प्रक्रिया में git rebase का उपयोग करते हैं।

इल्या आयुव , क्यूए लीड और व्लादिस्लाव चेर्नोव , रिलीज इंजीनियर

Git rebase "बटन पर"

गित प्रवाह

समस्या का बयान

मुख्य कार्य

कार्यान्वयन

निष्कर्ष

More articles: