1

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

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

考虑这个基本图：

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 重新定位到特性分支将包括合并到 staging 分支时的那些更改）。

4

1 回答 1

0

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

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

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

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

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

另外，如果需要记录三个主要分支之间的关系，可以将它们合并到一起：squash merge featureinto master-> merge masterinto development-> merge developmentinto stagingbranch -> delete featurebranch。那么提交历史将是：

...---A---B---C---M         master
                   \
  ...---G---H---I---M'      development
                     \
    ...---J---K---L---M''   staging
于 2017-11-07T01:56:53.707 回答