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

Question

我有以下情况：

一台内部服务器（server1），主仓库带有2个分支master和dev ，四个开发人员，具有git的3个副本，与dev的分支一起工作

规则：

1. 开发人员无法触摸或合并server1 / master
2. 每个开发人员在工作之前和推送之前都需要更新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

我想知道

1. 我的问题的最佳工作流程定义是什么
2. 每个开发人员的git命令是什么
3. 如果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点：对我来说，这似乎是典型的主题分支工作流程 ，通常是一个非常好的主意。

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

如果合并他们的话题回到之前改变你的工作流程，让开发人员在最新的一组变化的拉dev有一个机会，你能避免rebase在通常情况下。 唯一的例外是，在此期间没有人将新更改推送到dev ，因此有必要使用git pull --rebase 。 这应该解决第3点。

我还可以通过以下方式修改规则： 切勿直接对dev进行承诺。 您真正想要在此分支上看到的唯一内容是合并。 为什么？ 因此， git log --first-parent dev为您提供了历史记录的高级概述。

Answer 3

也许您应该看看git工作流程的示例，例如Atlassian上的示例。 《 战es》一书中的git可能有用，它讨论了一些虚构的设置要做的事（以及如何出错）的例子。 并且不要忘记阅读git书中的内容 。

git的一大优点是创建和操作分支既便宜又容易。 在分支上工作并将其合并到另一个分支，或将其嫁接到顶部几乎是无风险的。 切换分支很容易。 一定要利用这一点。 让开发人员按自己的意愿工作（家用计算机上的一个分支或十几个分支无关紧要，这是一个私人决定）。

一定要坚持每次提交都是一个逻辑上的更改（而不是“放弃一天的工作，明天再继续”）。 了解如何进行一连串更改（包括回溯，死胡同，不合逻辑的更改）以及如何创建干净，结构化的提交历史记录。 坚持清晰，有意义的提交消息。

我会做一个不太重要的项目（也许有些“不错”）进行一些试验。 特别是如果您已习惯于另一个VCS，则使用grok git需要花费一些时间。 学习如何创建分支和标签，学习git stash ，迟早会做错事，养成为我严重搞砸的情况设置后备功能的习惯已经为我节省了很多时间...