Git在測試環境上分支

Question

我開始在一家剛使用git的公司工作。 我需要一個很好的建議。 首先，我想談一談當前的工作流程。

團隊的工作流程與常規git基本有很大不同。 分支機構是

Local (feature/hotfix branch from Dev) -> Dev -> Test -> Prod

環境

Dev -> Test -> Prod

1. 每個分支都有不同的配置文件（尚無解決方案。但是我將首先解決此問題），因此，我們無法合並分支。
2. 開發人員正在使用Local（功能/修補程序分支），並將其推入合並到Dev分支中，並在Dev環境中發布其版本（只是補丁版本不斷增加（1.0.xxx），我知道這樣做不是一件好事。）
3. 然后他們將所做的更改挑選到Test分支中。 並且，他們在測試環境上發布了新版本。 UAT在這里令人陶醉。
4. 當開發人員想要將他們的更改發布到生產環境中時，他們還會選擇更改。 並在產品環境中發布新版本。

這里的第一個問題是，由於配置文件的原因，我們無法合並分支，因此我們無法很好地觀察分支的歷史。

第二個問題是，某些更改應在測試環境1-2上停留兩周，更改可能具有長壽命或短壽命。

第三個問題，我們不能使用git特性，例如合並和拉取請求。 我們想使用PR進行代碼審查等等。 這對我們很重要。

我可以說在這種情況下，部署過程和版本控制系統是混合的。 因此，我們想使用git-flow之類的東西。 雖然， 我們希望保留這三個環境（開發，測試和生產），並且主要目標是合並分支並使用拉取請求

假設，我們只有開發和掌握分支機構。 開發人員在功能分支上工作。 並將其功能合並到開發中。接下來，我們為測試環境創建了一個發布分支。 但是，我們應該為不同的生命周期變更集做什么呢？

我們如何將發布分支合並到master分支中？ 我們應該如何在git分支上處理測試環境？

例如;

release 1.3.0 -具有一項功能，應在測試環境中保留2周，然后再進入生產環境

release 1.4.0 -有人添加了一項新功能，應在幾天內用於生產環境。 （雖然release 1.3.0仍然有效。）

因此，測試環境將具有這兩個功能，並且產品在幾天后應具有最新的功能。 但是release 1.4.0分支具有這兩個功能。 我應該將什么合並到生產分支中？

我們應該使用不同於git-flow的東西嗎？ 您有什么建議？

Answer 1

那是很多不同的問題。 我將嘗試回答我認為最重要的問題。

您現有的工作流程聽起來像是顛覆之類的東西，在這種情況下，通常避免通過采摘來避免合並。 在git中，首選絕對是合並。

您給出的不合並分支的主要原因是您想使配置文件保持不同。 但這並不是您似乎想的那樣大的問題。

假設您在Dev有一個配置文件config.json ，而在Test有一個不同的內容。

你可以這樣做

# register a merge driver named 'ours' that uses the command 'true' to always return 0
git config --global merge.ours.driver true

git checkout Dev
echo 'config.json merge=ours' >> .gitattributes
git add .gitattributes
git commit -m 'Preserve config.json during merges'

git checkout Test
# copy the same commit, since we want the same setting in all branches
git cherry-pick Dev

# now, when you merge, config.json will be ignored
git merge Dev

完整的例子在這里

因此，這將使合並分支成為可能，這將解決您的第一個和第二個問題。 向此添加PR也應該可行，從而解決您的第三個問題。