文山网站开发大数据营销系统怎么样
大家好，我是 17。
今天和大家一起用前面学过的命令做过实践。
git 命令实战
你在分支 A,一个同事在分支 B fix 了一个bug。你不方便 merge 分支B,只想更新这个 fix bug 的提交。
最先想到的是 cherry-pick，但还有两个办法，git restore，和 patch。相比较来说，如果 fix 已经提交到远程，cherry-pick 是最佳的，git restore 也可以，但是还得提交一次。如果网络不通，那只能用 patch了。
修改上次提交的 message 可以用 git commit --amend，那如果是修改上上次提交的 message 呢？
方案一 reset + chery-pick
git log --oneline081b00b (HEAD -> master) 第二次提交
451ddbc 第一次提交
如果要修改第一次提交的提交信息，需要先退回到第一次提交,再修改提交信息
git reset --hard HEAD^
git commit --amend -m '第一次提交补充'
修改完第一次提交的信息，我们用第二条提交的 commid id 恢复第二条信息
git cherry-pick 081b00b
也许你会问，直接 把 HEAD reset 到 081b00b 可以吗？答案是不可以。因为执行 cherry-pick 后，虽然内容和 message 都一样，但这本质上却是一个新的提交。无法从这个提交回到 081b00b。
方案二 rebase
用 rebase 有一个前提，提交次数 >2
git rebase -i HEAD~2
在 dev 分支上开发完了，发现提交记录太多太乱了，提交主干的时候想合成一个提交，将来查的时候也好查。
git merge-base master dev输出：caa12ecabf18b0b7247f07481b01946f8b548d94git reset --soft caa12ecabf18b0b7247f07481b01946f8b548d94git commit 'feat:登录'
示例把所有修改合成一个提交，也可以分成几次提交。如果那样的话，需要用 --mixed 参数 ，把暂存区也还原。
用分支开发的时候，合并到主干可能会产生分叉。如果不想分叉呢？也是可以做到的。
场景一 从master创建分支 dev 后，master 没有修改，合并的时候，不会有分叉。
场景二 从master创建分支 dev 后，master 有修改，合并的时候，有分叉，为了避免出现分叉，不直接在 master 分支执行 merge，而是在 dev 分支 执行 rebase ，然后在 master 再执行 merge。
git switch dev
git rebase master
git switch master
git merge dev
这样在 master 分支上就不会有分叉了。
rebase 的过程相当于把 dev的提交一个一个的重新提交到 master 分支，可能有冲突。解决冲突的办法有二，可以手动解决，也可以自动解决（前面讲 checkout 时有讲）。解决完了 git rebase --continue
我有好几个分支，git 怎么知道我在哪个分支呢？
cat .git/HEAD输出：ref: refs/heads/dev2
原来是 HEAD 的功劳。HEAD 可以理解成一个引用，它一般情况下是指向分支，有时也指出 commit id。
当你执行 git commit 的时候生成节点 A，A 把 HEAD 认作父节点 ,HEAD 再指向 A。
当你执行 git reset B 的时候 HEAD 指向 B。
当你执行 git checkout C 的时候，HEAD 指向 commit C，这时因为没有分支指向 C,HEAD 这时的状态叫 detatch(分离） 状态。
当你执行 git checkout dev 的时候，HEAD 指向 分支 dev。
美化
毫无章法的提交会让人感觉混乱。如果所有的提交都整齐划一就会让人有正规军的感觉。适当的美化可以让我们用很小的付出得到较大的回报，在实际项目中提交的信息一定要注意用统一清晰的格式。
提交信息格式化
具体的内容可能参看阮一锋老师的文章 Commit message 和 Change log 编写指南
实操作的时候，注意要结合实际。
提交历史要清晰
在代码 push 之前，最好是先做个检查，对提交做一些调整。可以用之前介绍过的 rebase。一个好的提交历史不仅可以让后面查找的时候方便，也会给别人留下严谨的印象。