git合并最佳实践

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

我的工作流程是：

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

好了，现在我对这个

//不太确定，继续进行dev

方面的工作。 我想知道在第一次合并之后，如果我继续推进合并的分支，它是否会拆分提交。问题是：它到底是如何工作的

---

另一件事是合并这些提交。合并是否应仅在

完成的功能

提交或

完成的功能

+

所有中间检查点

也提交的情况下进行？如果选择第二个选项，如何分割这些提交？

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

---

通常不鼓励使用寿命长的要素分支。在git中，分支是廉价的，除了特殊的分支（开发、主控、发布分支）不应该重用。功能（又名主题）分支应该是短期的。

如果您单独处理项目，此工作流就足够了。但是，如果您与几个人一起工作，我会使用，例如。当然，你也可以修改它。忘了提一下，但我在这个项目上是独自工作的，这就是为什么我选择不为不同的特性制作单独的分支。谢谢你的文章！