Question

我遇到以下情况：

一个内部服务器（server1），主要仓库有2个分支主和 dev ，四个开发人员使用git的3个克隆与 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)

在dev分支上测试后：

git push origin dev

我想知道

我的问题的最佳工作流程定义是什么
每个开发人员的git命令是什么
如果 git pull 是正确的，或者更好地拥有 git rebase -i dev 或更改此命令的位置

提前谢谢

Answer 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 。将分支推送到另一个存储库后，应该考虑将分支结构“锁定”，而不再修改它。否则，下次推送时，您将导致服务器出现问题，并在其他开发人员试图拉动时导致问题。

Answer 2

对于第1点：对我来说它看起来像一个典型的topic branch workflow，一般来说是一个非常好的主意。

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

如果您更改工作流程以使开发人员在将其主题合并回dev之前提取最新的更改集，则有可能在常见情况下避免rebase。唯一的例外是在此期间没有人将新的更改推送到dev，因此需要git pull --rebase。这应该解决第3点。

我还会修改规则：永远直接在dev上提交。你真正想要在这个分支上看到的唯一的东西是合并。为什么？因此git log --first-parent dev为您提供了很好的历史记录。

Answer 3

也许你应该四处寻找git工作流程的例子，例如： Atlassian处的那些。 git in the trenches本书可能很有用，它讨论了一些虚构的设置要做的事情（以及它可能出错的一些例子）。不要忘记阅读git book。

git的一大优势是创建和操作分支既便宜又容易。在分支机构上工作并将其合并到另一个分支机构中，或者将其移植到顶部，几乎没有风险。切换分支很容易。要利用这一点。让开发人员按照他们的意愿工作（他们的家用机器上有一个分支，或者十几个无关紧要，这是私人决定）。

坚持每次提交都是一次逻辑更改（而不是“转储一天的工作，明天继续”）。学习如何进行一系列更改（使用回溯，死角，不合逻辑的更改）并从中创建一个干净的，结构化的提交历史记录。坚持清晰，有意义的提交信息。

我会采取一个不那么重要的项目（有些“很高兴，或许”）进行一些实验。特别是如果你习惯了另一个VCS，那么去grok git需要花时间去处理它。了解如何创建分支和标签，了解git stash，迟早会做错事，并养成为案件设置后备的习惯我搞砸了我已经救了几次......

git workflow：几个开发人员，只有2个分支

3 个答案: