我目前正在為我的團隊制定作業流程。我們收到的建議是使用 GitFlow 方案。這個方案可以放在一個圖表上，如下所示：
但是，我有一個關于如何管理特定案例的問題。由于我們的活動，我們必須維護我們的客戶可能仍在使用且出于各種原因不想更新的先前版本。
在 GitFlow 方案中，主干應該是發布發生的地方。主干中的提交是一個潛在的可交付產品，應該收到一個版本標簽。
那么......我怎樣才能回到過去，為舊版本生成修復程式并將其合并回主干以生成該版本？
另一個問題是，如果我不希望將該修復程式帶回后備箱？
It seems to me that this workflow is more adapted to software that continually pushes new versions to their customers, such as mobile apps, but not industrial products, even if they are built from a CI. But maybe I am missing something here, hence my question
uj5u.com熱心網友回復：
讓我們把你的問題分成兩部分：
我怎樣才能回到過去，[為] 修復舊版本？
你在第二張圖中的問號完全適合這個。只需找到您要修改的版本的標簽，將其分支（也許將其命名為類似hotfix/1.1.1），然后提交您的新更改。然后標記“發布”。
對于問題的后半部分：
我怎樣才能......將它合并回后備箱？
尤其是如果：
我不想把那個修復帶回后備箱？
如果您確實希望將該修補程式集成到主干中，這很容易 - 只需將其合并（如果您有沖突，請像往常一樣解決它們）。
如果您不想將該修補程式集成到主干中，您有一些選擇：
hotfix/1.1.1無限期地留在你身邊。分支機構超級便宜，這是許多公司使用的有效策略。（事實上??，許多公司master在 Git-Flow-Like 策略中完全取消了分支，只是release/無限期地保留他們的分支。）如果你走這條路，你可能有一天會有很多遠程分支，在這種情況下，我會建議使用偽目錄斜杠字符（/如建議用）在您的分支名hotfix/1.1.1。許多 Git 客戶端允許您通過偽目錄匯總分支，因此您不必查看數百個您不感興趣的分支（通過hotfix/在視圖中折疊目錄。）- 我個人的偏好是不要永遠保留大量的修補程式分支，因此您可以花點心思將修補程式分支合并回主干，但告訴 Git 忽略更改。執行此操作后，您可以洗掉修補程式分支，因為所有資訊都包含在主干中的新標記提交中。
以下是在不進行更改的情況下合并分支的方法：
git fetch
git branch -D main # in case you have an old copy of it
git switch main # now you should be up to date with origin/main
git merge --strategy=ours hotfix/1.1.1 # bring in commits without their changes!
請注意，與我們的策略合并對作業副本沒有影響。它的唯一目的是將來自 hotfix 分支的提交引入，以便您不再需要維護 hotfix 分支；此時您可以簡單地將其洗掉。
提示：請善待并使用描述性提交訊息解釋您這樣做以及為什么！
你沒有問這個，但根據我的經驗，它最終肯定會出現：
如果我想集成修補程式中的某些更改而不是其他更改，該怎么辦？
這是一個很棒的問題！有多種方法可以給這只貓剝皮，在我了解與我們的合并策略之前，我會簡單地使用--no-commit標志進行合并，手動撤消我不想保留的內容，然后提交合并。這樣做的缺點是，您只能相信合并提交已正確完成，并且可能很難（呃）排除故障。如果你走這條路，一條描述性的提交訊息解釋你做了什么以及為什么在這里很重要。
我目前處理這個問題的首選方法是將修補程式更改分成 2 部分（通常是 2 次提交，但也可能更多）。確保您要集成的所有提交首先在修補程式分支上，然后您不想集成的提交稍后出現。（最有可能rebase -i的是，如果事后需要，您可以使用重新排序它們，只要在您標記它并發布它之前。）接下來的步驟非常簡單：
git fetch
git switch -c merge-hotfix-into-main origin/main --no-track # create a temp branch
git merge <last-commit-you-want-to-integrate> # take in commits and changes
git merge --strategy=ours hotfix/1.1.1 # bring in remaining commits without changes
git branch -D main # in case you have an old copy of it
git switch main #
git merge merge-hotfix-into-main --no-ff
Note, the temporary branch merge-hotfix-into-main isn't actually needed here, but to stay with the spirit of --no-ff merges into main as defined by Git Flow, every first parent commit into main should represent a release, and that wouldn't be true unless the temp branch and it's 2 merge commits get brought in with a single merge commit on main.
Side Note: This is a minor point, but your first diagram appears to be violating one Git Flow principle, mainly, that tagged releases aren't making their way back to develop quick enough. Typically you'd have your blue dots pointing back to develop right away. You can see 3 blue dot releases that aren't in develop yet.
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/341654.html
標籤：git continuous-integration git-flow cicd
上一篇：Git/Windows-簽出分支（和拉取/合并分支）時的區分大小寫問題。受影響的檔案在Windows資源管理器中全部為小寫