2014-10-29 59 views
0

由於業務需求和舊習慣的結合,我們的QA/BA團隊成員似乎認爲他們需要能夠看似挑選任何開發工作的組合潛在發佈候選人在發佈時間。這讓我感到擔憂,因爲目前這會讓很多git「疤痕組織」在恢復和還原恢復提交以及「註釋掉」和「取消註釋」提交方面變得更糟。 (可悲的是:在darcs中,這對於給定的工具來說可能更容易實現,但我們當然不會使用我們使用git的darcs。)昨天在做一些研究時,我遇到了Branch per feature(BPF)工作流自動化工作及其維持「完全隔離,全面整合」(TITI)的過程。現在我試圖弄清楚在工作環境中是否可以實現類似的東西,希望不需要增加太多額外的開發過程工作,也不必將嬰兒用洗澡水倒出來這樣做。 (更不用提其他問題了,我可能會對我們的QA/BA結構表現出一些自動化...)GitHub和「git bpf」:PR和git rerere

BPF中的TITI過程在很大程度上依賴於共享git rerere高速緩存,以便集成合並可以在一次性分支機構或整合分支機構,但在構建發佈候選人(QA)分支機構時可以重新使用櫻桃採摘流程。這裏的特定點不是合併到「源」分支中,以使源分支完全隔離。所以我想弄清楚如何在我們使用GitHub PRs作爲集成合並的工作流程中工作。很明顯,PR目前不允許進行復雜的合併,而當前的工作流程是修復源分支中的合併衝突,但如果我們嘗試BPF,那將違反隔離原則。理論上我們可以做一次性合併技術,但是如何設置GitHub來共享rerere緩存?

TL; DR:什麼是處理共享的最佳方式rerere 繼續使用GitHub的引入請求,還可能因爲整合/只需要整合合併的單位? (Hacky Aside:目前我們只需要在我們的一個倉庫中執行此操作,並且該倉庫目前在GitHub for Enterprises的倉庫中託管,因此存在一種很小的可能性,我可以說服管理員使用SSH訪問破解機器上的git配置以啓用共享資源和自動rerere。但是依賴這種攻擊存在很多脆弱性,包括來自其他業務部門的潛在問題,爲什麼他們不能做什麼我們在公共GitHub上做的事情,也只是潛在的GitHub更新打破任何git配置黑客的問題,假設他們甚至在第一個地方工作...)

回答

0

這似乎是我在這裏的大舉動簡直失去了明亮閃亮的「Merge Pull Request」的「安全毯」 GitHub中的按鈕。我正在考慮進行這種工作流調整的團隊具有廣泛的技能水平,現在焦點集中在基於UI的工作流程上(GitHub,Windows的GitHub和Visual Studio的啓用Git的團隊資源管理器),因此可能對教GitHub新技巧,而不是我的開發人員...

它看起來像關鍵只是做更多「離線」公關合並沒有閃亮的綠色按鈕。關鍵的實現是,爲了保持PR閉包看起來與我們今天的合理相似(我們嘗試將PR作爲同行評審強制執行),當PR無法自動合併時,它成爲代碼評論者的附加任務,做最後的整合合併。我擔心這可能意味着帶有集成問題的PR很快就會變得「陳舊」,直到一位更高級的開發人員有足夠的時間對合並進行檢查和評估爲止,但從長遠來看這也可能不是一件壞事。

hub工具當然會幫助這個工作流程。這隻會增加命令行學習的負擔,以培養開發人員。