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

我有以下情况：

一个内部服务器server1，主repo有两个分支master和dev， 四名开发人员，拥有3个git克隆，使用开发人员的分支

规则：

开发人员无法触摸或合并server1/master 每个开发人员都需要在工作之前和推送之前更新server1/master的版本 我想到这个过程： 开发者1必须做到： 在git克隆和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或更改此命令的位置

---

提前感谢

对于小型企业来说，这是一个不错的工作流程，您相信每个开发人员都可以在服务器上查看开发分支。这基本上是我在家里做的事情

更常见的工作流是，开发人员将其更改推回到特殊的审阅分支：

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。一旦将分支推到另一个存储库，就应该考虑分支结构被锁定，而不再修改它。否则，您将在下次推送时给服务器带来问题，并在其他开发人员尝试拉送时给他们带来问题。

对于第1点：我认为这是一个典型的问题，通常是一个非常好的主意

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

如果您更改工作流程，使开发人员在将主题合并回dev之前获取最新的一组更改，那么您有可能避免在常见情况下重新设置基础。唯一的例外是，在此期间没有人向开发人员推送新的更改，因此有必要使用git pull-rebase。这应涉及第3点

---

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

也许您应该四处寻找git工作流的示例，例如位于。这本书可能很有用，它讨论了一些要做的事情的例子，以及一个与你不太相似的虚构的设置是如何出错的。别忘了读一遍你的文章

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

一定要坚持每一次提交都是一次逻辑上的更改，而不是放弃一天的工作，明天再继续。了解如何使用回溯、死角、不合逻辑的顺序进行一系列更改，并从中创建一个干净、结构化的提交历史记录。坚持清晰、有意义的提交消息

我会选择一个不太重要的项目，一些好的项目，也许可以做一点实验。特别是如果你已经习惯了另一家风投，那么使用GrokGit需要时间。了解如何创建分支和标记，了解git隐藏，你迟早会出错，并且养成为我搞砸的情况设置备用方案的习惯已经为我节省了好几次了…

你的再次同步可能应该是git pull-rebase，然后检查没有任何问题。我同意。我自己的 工作流通常是执行git pull，然后如果我不喜欢合并的结果，则执行一个重基。但我开始认为git拉-再基是更好的方法。