git 合并最佳实践

问题描述

最近我一直在做项目，并在 master 旁边创建了一个 dev 分支。 我一直在推动“检查点”的新提交（只是保存我的工作）和完成的功能。 完成功能后，我总是与主人合并。

我的工作流程是：

1) git push origin dev with_some_commit // few times
2) git checkout master
3) git merge dev
4) git push origin master

所以对我来说是一个典型的流程（直到现在）。

我最近想知道这种类型的工作流程是否正确。 到目前为止，我将我的工作流程想象为：

// before merge:
---o---o---o---> master
            \---o---o--->dev

// after a marge:
---o---o---o-------------> master
            \---o---o--/
// and continue on dev:
---o---o---o----------------> master
            \---o---o--/  \---o---> dev

现在我不太确定这 // and continue on dev 事情。 我想知道是否真的在第一次合并之后，如果我继续推动合并的分支，它会拆分提交。问题是：它是如何真正起作用的？

另一件事是合并这些提交。合并应该只与 finished features 提交还是 finished features + all the in-between checkpoint 提交一起完成？如果是第二个选项，如何拆分这些提交？

解决方法

有几种流行的分支策略。 Atlassian（Jira 和 BitBucket 背后的团队）对 Gitflow Workflow 有很好的指导，这是一种 git flow - 最受欢迎的策略之一。

通常不鼓励长期存在的功能分支。 git 中的分支很便宜，除了特殊的分支（develop、master、releases 分支）不应该重用。功能（又名主题）分支应该是短暂的。