Question

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

当正在处理新的任务/功能时，我们将首先从master创建我们的功能分支，根据需要多次提交它，然后使用temp分支将其全部压缩到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重新绑定到功能分支将在合并到分段分支时包含这些更改）。 / p>

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

然后提交历史将是（commit M是来自feature分支的squash merged commit，commit M'是来自master分支的提交提交，提交M''也是来自master分支机构的提交：

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

这会使您的主要分支master，development和staging作为单独的线性结构。

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

此外，如果您需要记录三个主要分支之间的关系，您可以将它们合并在一起：将合并feature压缩到master - ＆gt;将master合并到development - ＆gt;将development合并到staging分支 - ＆gt;删除feature分支。然后提交历史将是：

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

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

1 个答案: