【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令( 二 )


【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令
本文插图
【【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令】

如果我们想把 dev 合并到 master , 就会出现一个合并冲突:你想要标题是 Hello! 还是 Hey!?
当尝试合并这些分支时 , Git 会向你展示冲突出现的位置 。 我们可以手动移除我们不想保留的修改 , 保存这些修改 , 再次添加这个已修改的文件 , 然后提交这些修改 。
【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令
本文插图

完成!尽管合并冲突往往很让人厌烦 , 但这是合理的:Git 不应该瞎猜我们想要保留哪些修改 。
变基(Rebasing)
我们刚看到可通过执行 git merge 将一个分支的修改应用到另一个分支 。 另一种可将一个分支的修改融入到另一个分支的方式是执行 git rebase 。
git rebase 会将当前分支的提交复制到指定的分支之上 。
【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令
本文插图

完美 , 现在我们在 dev 分支上获取了 master 分支上的所有修改 。
变基与合并有一个重大的区别:Git 不会尝试确定要保留或不保留哪些文件 。 我们执行 rebase 的分支总是含有我们想要保留的最新近的修改!这样我们不会遇到任何合并冲突 , 而且可以保留一个漂亮的、线性的 Git 历史记录 。
上面这个例子展示了在 master 分支上的变基 。 但是 , 在更大型的项目中 , 你通常不需要这样的操作 。 git rebase 在为复制的提交创建新的 hash 时会修改项目的历史记录 。
如果你在开发一个 feature 分支并且 master 分支已经更新过 , 那么变基就很好用 。 你可以在你的分支上获取所有更新 , 这能防止未来出现合并冲突 。
交互式变基(Interactive Rebase)
在为提交执行变基之前 , 我们可以修改它们!我们可以使用交互式变基来完成这一任务 。 交互式变基在你当前开发的分支上以及想要修改某些提交时会很有用 。
在我们正在 rebase 的提交上 , 我们可以执行以下 6 个动作:
reword:修改提交信息;
edit:修改此提交;
squash:将提交融合到前一个提交中;
fixup:将提交融合到前一个提交中 , 不保留该提交的日志消息;
exec:在每个提交上运行我们想要 rebase 的命令;
drop:移除该提交 。
很棒!这样我们就能完全控制我们的提交了 。 如果你想要移除一个提交 , 只需 drop 即可 。
【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令
本文插图

如果你想把多个提交融合到一起以便得到清晰的提交历史 , 那也没有问题!
【机器之心】工作流一目了然,看小姐姐用动图展示10大Git命令
本文插图

交互式变基能为你在 rebase 时提供大量控制 , 甚至可以控制当前的活动分支 。
重置(Resetting)
当我们不想要之前提交的修改时 , 就会用到这个命令 。 也许这是一个 WIP 提交或者可能是引入了 bug 的提交 , 这时候就要执行 git reset 。
git reset 能让我们不再使用当前台面上的文件 , 让我们可以控制 HEAD 应该指向的位置 。
软重置
软重置会将 HEAD 移至指定的提交(或与 HEAD 相比的提交的索引) , 而不会移除该提交之后加入的修改!
假设我们不想保留添加了一个 style.css 文件的提交 9e78i , 而且我们也不想保留添加了一个 index.js 文件的提交 035cc 。 但是 , 我们确实又想要保留新添加的 style.css 和 index.js 文件!这是软重置的一个完美用例 。


推荐阅读