来自mercurial,我使用分支来组织功能.当然,我也想在我的历史中看到这种工作流程.
我使用git开始了我的新项目并完成了我的第一个功能.合并该功能时,我意识到git使用快进,即如果可能,它会将我的更改直接应用到主分支并忘记我的分支.
因此,思考未来:我是唯一一个从事这个项目的人.如果我使用git的默认方法(快进合并),我的历史将导致一个巨大的主分支.没有人知道我为每个功能使用了一个单独的分支,因为最后我只有那个巨大的主分支.这看起来不专业吗？
通过这种推理,我不想要快进合并,也不知道为什么它是默认的.这有什么好处的？
让我们假设我们有一个master分支.
然后我们创建一个 newbranch
git checkout -b newbranch
和两个新提交到newbranch:commit1和commit2
然后我们切换到master并制作 cherry-pick
git checkout master
git cherry-pick hash_of_commit1
展望gitk我们看到commit1和樱桃采摘的版本有不同的哈希值,所以在技术上它们是两个不同的提交.
最后我们合并newbranch到master:
git merge newbranch
并且看到这两个具有不同哈希值的提交合并没有问题,尽管它们暗示应该应用相同的更改两次,因此其中一个应该失败.
git是否真的对提交的内容进行了智能分析,同时合并并确定更改不应该应用两次,或者这些提交在内部标记为链接在一起？