git 工作流程：几个开发人员，只有 2 个分支答案

【问题标题】：git workflow: several developers, only 2 branchesgit 工作流程：几个开发人员，只有 2 个分支
【发布时间】：2025-12-14 08:35:01
【问题描述】：

我有以下情况：

一个内部服务器 (server1)，主仓库有 2 个分支 master 和 dev，四名开发人员拥有 3 个 git 克隆，使用 dev

的分支

规则：

开发者无法触及或合并 server1/master
每个开发者在工作前和推送前都需要更新 server1/master 的版本

我想到了这个过程：开发人员 1 必须执行以下操作：在 git clone 和可能 git pull 之后，每天都会是这样的：

git checkout dev
git pull (for synch every modification from other developers)
git checkout -b myModification (for making a branch from dev)

修改后添加并提交：

git checkout dev
git merge --no-ff myModification
*git pull (for fetching  modification in dev made in the meanwhile from others developers)

在开发分支上测试后：

git push origin dev

我想知道

什么是我的问题的最佳工作流定义
每个开发者的 git 命令是什么
如果git pull是正确的或者最好有git rebase -i dev或者改变这个命令的位置

提前谢谢你

【问题讨论】：

标签： git version-control push git-remote branching-strategy

【解决方案1】：

对于小型商店来说，这不是一个糟糕的工作流程，您相信每个开发人员都会检查服务器上的 dev 分支。这基本上就是我在家里做的事情。

更常见的工作流程是让开发人员将他们的更改推送回一个特殊的“审查”分支：

git push --dry-run origin dev:refs/heads/falk/dev
(satisfied this won't make a mess)
git push dev:refs/heads/falk/dev

然后我会要求项目管理员将 falk/dev 分支合并到 dev 分支中。

如果你有足够多的开发人员，他们中的一些人可能会搞砸，项目管理员会设置权限，以便开发人员不能直接推送给开发人员。

通过调整权限和 git 挂钩，您可以安排在完成合并之前需要一个正式的代码审查流程。

最后，整个事情可以通过使用 Gerrit 来管理主存储库来自动化。不过，管理这些东西远远高于我的工资等级。

好的，回答你的具体问题：

1,2。您的工作流程应该按照您编写的方式工作，尽管我个人通常不会为创建“myModification”功能分支而烦恼，因为它只存在于本地工作区中，而且无论如何它都是临时的。您的开发人员可能会开发自己的风格。

所以我自己的工作流程如下：

# start work, pull in any remote changes first
git checkout dev
git pull
(work)
# sync up again, just in case
git pull
git push origin dev:refs/heads/falk/dev
(ask administrator to do the merge)

git pull 是您要使用的命令。这可能会导致冲突，开发人员必须手动解决。

git rebase 在推入或拉入其他存储库时可能会给您带来麻烦，因为它实际上会修改分支结构。您应该只在自己的本地工作区中使用 git rebase。将分支推送到另一个存储库后，您应该将分支结构视为“锁定”并且不再对其进行修改。否则，你下次推送的时候会给服务器带来问题，而其他开发者尝试拉取的时候也会出现问题。

【讨论】：

您的# sync up again 应该是git pull --rebase，然后检查是否有任何问题。
我同意。我自己的工作流程通常是做git pull，然后如果我不喜欢结果的合并，就执行一个变基。但我开始认为git pull --rebase 是更好的方法。

【解决方案2】：

也许您应该四处寻找 git 工作流程的示例，例如Atlassian 的那些。 git in the trenches 这本书可能很有用，它讨论了一些与您的设置不太一样的虚构设置要做的事情（以及它如何出错）的示例。并且不要忘记通过git book阅读您的方式。

git 的一大优点是创建和操作分支既便宜又容易。在一个分支上工作并将其合并到另一个分支上，或者将其嫁接在上面，几乎没有风险。切换分支很容易。一定要利用这一点。让开发人员随心所欲地工作（他们家机器上的一个分支或十几个分支都没有关系，这是一个私人决定）。

不要坚持每次提交都是一个单一的逻辑更改（而不是“放弃一天的工作，明天继续”）。了解如何进行一系列更改（包括回溯、死胡同、不合逻辑的更改）并从中创建干净、结构化的提交历史记录。坚持清晰、有意义的提交信息。

我会做一个不太重要的项目（也许是一些“很高兴拥有”）来进行一些实验。特别是如果您习惯了另一个 VCS，那么使用 grok git 需要花费一些时间。学习如何创建分支和标签，了解git stash，你会迟早会做错事，并且养成为我搞砸的情况设置后备的习惯拯救了我已经好几次了……

【讨论】：

【解决方案3】：

对于第 1 点：在我看来，这就像一个典型的 topic branch workflow，总的来说是一个非常好的主意。

对于第 2 点：开发人员需要了解并理解此工作流的基本 git 命令集：branch、pull (--rebase)、commit、merge。

如果您更改工作流程以使开发人员在将他们的主题合并回dev 之前引入最新的更改集，那么您有可能在常见情况下避免使用rebase。唯一的例外是在此期间没有人向dev 推送新的更改，那么git pull --rebase 就变得很有必要了。这应该解决第 3 点。

我还将通过以下方式修改规则：从不直接在 dev 上提交。您真正想在此分支上看到的唯一内容是合并。为什么？所以git log --first-parent dev 给你一个很好的关于你的历史的高级概述。

【讨论】：