时间戳

首页 > 解决方案 > git合并最佳实践

git - 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提交来进行合并？如果是第二种选择，如何拆分这些提交？

标签： gitgithubgit-mergegit-branchgit-workflow

解决方案

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

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

推荐阅读