保持干净的 git 分支，但同时不会引起冲突

Question

我一直致力于让我的团队的 git 工作流程更加简洁明了。我们的团队使用master、staging 和development 分支作为我们的构建服务器。

当一个新的任务/功能正在开发中时，我们将首先从 master 创建我们的功能分支，根据需要多次提交，然后使用临时分支将其全部压缩为 1 个提交并移动它分期或开发。

考虑这个基本图：

Master
   |
Staging
   | 
Development ——> [F1] ——> [F2]
   |
*Temporary* ——> [F2] 
   |
Feature1 ——> [A ——> B ——> C] = [F1]
   |
Feature2 ——> [A ——> B ——> C] = [F2]

在这里，我们看到所有分支的起始位置排成一行。每个功能的提交都是隔离的并保持在一起。当特性移动到上游时，特性的提交被压缩，然后合并到上游分支。例如，将功能移至开发阶段意味着：

    git checkout development;            # Switch to Development
    git pull --rebase $DEV_REMOTE;       # Rebase changes onto development
    git checkout $MASTER;                # Switch to master branch
    git checkout -b $SQUASH;             # So that we can clone a squash branch from it
    git merge --squash $FEATURE_BRANCH;  # Merge in the feature
    git commit -m "Testing ($FEATURE_BRANCH)"; # Meaningfully Commit
    git rebase $DEV_LOCAL;               # Rebase Local Dev onto Feature
    git checkout $DEV_LOCAL;             # Switch back to Dev
    git merge $SQUASH;                   # Merge on the feature
    git branch -D $SQUASH;               # Delete Squash Branch

这在短时间内运行良好，直到我在挤压时遇到了第一次冲突。我不确定更改是在哪里进行的，以及为什么 git 不能自动使用历史记录来解决它。这是一个非常基本的输入/输出交换。

我的问题是：有没有更好的方法来做到这一点？我们希望将我们的代码合并到 dev/staging 中，每个特性分支 1 次提交，而不会在开发测试时破坏/弄脏特性分支（将未批准的代码从 dev 重新定位到特性分支将包括合并到暂存分支时的这些更改）。

Answer 1

我建议你分别从 master 分支到 staging 和 development 分支中挑选合并的提交。

首先假设提交历史如下：

        D----E---F    feature
       /
...---A---B---C   master
...---G---H---I   development
...---J---K---L   staging

使用的命令如下：

git checkout master
git merge feature --squash
git checkout development
git cherry-pick master
git checkout staging
git cherry-pick master
git branch -D feature

然后提交历史将是（提交M是来自feature分支的壁球合并提交，提交M'是来自master分支的cherry-pick提交，提交M''是提交也是cherry - 从master 分支挑选）：

...---A---B---C---M     master
...---G---H---I---M'    development
...---J---K---L---M''   staging

这将使您的主要分支 master、development 和 staging 以独立的线性结构工作。

注意： squash 合并时是否有冲突，取决于你在feature 分支和master 分支上所做的更改。但无论是 squash 合并还是cherry-pick，您都可以使用-X 选项自动解决冲突。 -X ours 将通过将版本保留为当前分支来解决冲突文件。 -X theirs 将通过保持版本作为另一端来解决冲突文件。

另外，如果你需要记录三个主要分支之间的关系，你可以将它们合并在一起： squash 合并feature into master -> 合并master into development -> 合并development into staging 分支 -> 删除 feature 分支。那么提交历史将是：

...---A---B---C---M         master
                   \
  ...---G---H---I---M'      development
                     \
    ...---J---K---L---M''   staging