编辑：

只需继续提交dev并合并到master即可生成以下图表：

git log --oneline --graph --branches 
*   62d400f Second Merge branch 'dev'
|\  
| * 86cd761 Continue 2 dev after merge
| * b10e96b Continue dev after merge
* |   04dcd00 Merge branch 'dev'
|\ \  
| |/  
| * 80d5577 Continue dev
| * 7119020 Started to dev file
|/  
* 05350a5 Updated the file
* 9e70af0 Initial commit

但是，如果我删除dev然后再从master分支，我可以使用以下图表：

*   c39c881 Third Merge branch 'dev'
|\  
| * cab5dc5 Back on (new) dev
|/  
*   62d400f Second Merge branch 'dev'
|\  
| * 86cd761 Continue 2 dev after merge
| * b10e96b Continue dev after merge
* |   04dcd00 Merge branch 'dev'
|\ \  
| |/  
| * 80d5577 Continue dev
| * 7119020 Started to dev file
|/  
* 05350a5 Updated the file
* 9e70af0 Initial commit

如果我错了，请纠正我，但这看起来更干净，不是吗？这就是为什么我天真地从master删除并重新分支的原因。

至于为什么我首先采用这种方法：我的master基本上是一个SVN，我只允许某些提交消息（因此提交的数量有限）。所以我在dev开发，当我准备就绪时，我合并为master并留下正确的提交消息。

上下文：

我使用this answer中描述的工作流程。我以某种方式意识到在将更改推送到SVN后，我必须删除dev并从master重新分支。

Answer 1

TL; DR

在Git中，指向给定提交（例如cf2308e）的名为 dev 的分支仍然是同一分支，即使您删除它并重新创建它。分支名称包含对提交的引用; Git并没有随身携带任何其他与分支相关的历史记录，因此您所做的事情对Git或您来说并不具有固有的用途。

合并后继续

我有一个主人和开发分支。每当我将dev合并为master时，我必须使用--no-ff（无快进）方法。

通常，当他们想要强制合并提交而不是快进时，会执行此操作。一些商店喜欢这样做以跟踪提交消息中的分支的合并，因为Git承诺实际上不携带任何分支信息。在Git中，分支成员资格是从提交的祖先推断出来的，而不是像在其他分布式版本控制系统中一样存储为显式数据。

然而，将合并的分支实际删除到＆＃34; reset dev。＆＃34;没有任何有用的理由。您可以继续在 dev 分支上进行开发，Git将足够聪明，在下次与 master 合并时不会重新合并相同的提交。

如果您只是想再次分支 master 的提示，则删除并重新创建 dev 并不能真正为您买任何东西。由于您没有使用有用名称的主题分支，并且您没有进行压缩提交，我的建议是在与 master合并后继续前进 dev

重置分支

执行此操作的唯一真实用例是，如果要合并除 dev 分支的提示之外的其他内容。在这种情况下，您可能希望丢弃 master 上已有的 dev 中的任何内容。如果是这样的话：

git checkout master
git merge --no-ff <some_commit>

git checkout dev
git reset --hard master
git push --force origin dev

请注意，如果您回放分支的尖端，则可能需要强制推送才能重置远程分支指针。 Rewinding还会强制任何人从您或从受祝福的存储库中撤出，以重新克隆或执行 dev 分支的强制重置。例如：

git checkout dev
git fetch --all
git reset --hard origin/dev

Answer 2

为了避免必须删除dev并从master重新创建，您可以在git reset --hard master分支上dev。

什么是更聪明的方式来重置＆＃34; Git中的开发分支？

编辑：

上下文：

2 个答案:

TL; DR

合并后继续

重置分支