GIT重学—进阶实战

这是我参与更文挑战的第11天，活动详情查看: 更文挑战

1, git rebase 与 git merge

git rebase 与git merge 解决了相同的问题，都是将一个分支的提交合并到另一个分支上，

(1), merge

merge 操作，切换到newBranch分支，合并master代码

git checkout newBranch
git merge master
复制代码

优势：merge它保留了分支的结构和历史提交目录，但是同时也导致了提交历史会被merge 污染

rebase是一个经常听到的，但是又掌握不太好的命令，rebase 合并又被称为：变基

(2), rebase

rebase操作它是把所有的提交压缩成一个patch, 然后把patch添加到目标分支里面，rebase会把原分支中的每一个提交创建全新的commits来重些项目历史记录。

git checkout newBranch
git rebase master
复制代码

优势：rebase会在一条线上展示历史记录，可以更清晰获取项目历史，它消除了merge所需的不必要的合并提交记录，同时，rebase合并变基的时候，会丢失提交的上下文信息，使我们无法看到真实的合并时间

2, 交互式git rebase -i

git checkout newBranch
git rebase -i master
复制代码

进入编辑页面，显示每一次的提交记录，可以编辑，也可以移除，重新调整提交记录，提交记录可以变成任何你想要的样子，

多个commit 需要合并为一个完整的commit提交

-i 就是指交互模式，说明你可以干预rebase这个事务的过程，包括设置commit message，进入编辑模式，有些常用参数需要了解

pick: 意味着包括提交，用这个commit提交信息

squash: 该命令使您可以将两个或多个提交合并为一个提交。提交被压缩到其上方的提交中

drop: 删除某次提交记录
复制代码

# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
复制代码

3, git merge 对比 git rebase

# git merge 
1，记录合并操作动作，很多是无用的合并信息
2，不会改变commitId,提交记录有先后顺序，但是分支看着不太整齐，
3，冲突只解决一次

# git rebase
1, 修改所有的commitId
2, 使得提交记录变成一条线，项目历史看着更简洁，提交历史更清晰
3，每个commit都需要解决冲突


复制代码

建议: 为了提交历史更清晰，更易于理解，使用rebase是一个明智，高效的选择

# 实战笔记
1，git rebase branchName   // 合并分支
2，如果有冲突,先解决冲突
3，git rebase --continue
4，git rebase -i HEAD  // 改变提交记录中的结构，顺序，历史记录等等
   

复制代码

4, git tag

为项目添加标记，打个标签

git tag  releaseV1.0.0
git push origin releaseV1.0.0
复制代码

注意： 当我们完成某一个需求的时候，准备发布上线，应该将此此完整的项目代码做个标记，并将这个，标记好的版本发布到线上，releaseV1.0.0 位标记名称， 标记的名称可以更好的语意话，方便代码的回滚，查找，定位

**标记是用于特定的点或提交历史，通常会用来标记发布版本的名称和版本号，有人问tag和分支有什么区别，其实，作用山都一样，一个完整的分支也可以用来发布，但是：打上标记的提交是固定的，不能随意改动，而且标记更具有语意话。

5, HEAD

HEAD 指向的就是当前分支的最新提交，即：最新的一次commitId

上一个版本就是HEAD^

上上一个版本就是HEAD^^

当然往上100个版本写100个^不太方便，所以写成HEAD~100

# 查看commitId
git log 
# 穿梭到特定的commitId位置
git reset --hard commitId  
# 要重返未来，查看命令历史
git reflog
复制代码

注意： git reflog 可以查看所有的分支的所有操作记录，包括commit, reset的操作，以及被删除的commit记录，和git log的区别在于它不能查看已经删除的commit记录

6, 实战操作

# 将加了tag的某个版本打包提取
  git archive -v releaseV0.1 > releaseV0.1.zip --format=zip
  
# 运行git的垃圾回收功能，清理历史快照
  git gc
  
# 将远程版本库的更新取回到本地的版本库，，默认拉取所有的分支
  git fetch

# 添加一个新的远程仓库，指定一个名字，
  git remote add origin https://xxxxxxxxx

# 查看所有分支的历史操作记录，包括commit, reset, 已经删除的
  git reflog
 
 # 撤销某次操作，此次操作之前和之后的commit都会保留，并且把这次撤销作为一次最新的提交
  git revert
  git revert HEAD  // 撤销前一次提交操作
  git revert HEAD --no-edit  // 撤销前一次操作，并以默认的xxx位提交原因
  
# 撤销多次操作，并最后做一次统一的提交
  git revert -n HEAD
 
# 暂存区和工作区中的任何内容都被丢弃，并把HEAD指向commit
  git reset --hard commit

# 暂存区和工作区中的内容不做任何改变，仅仅把HEAD指向commit
  git reset --soft commit
  
# 合并分支的一条或几条记录到当前分支末梢
  git cherry-pick commitId
  
# 显示带提交差异对比的历史记录
  git log  文件
  
# 输出简短的历史记录
  git log --pretty=oneline
  
  
# 将未提交的文件保存到缓存中
  git stash save 'xxxx'
 
# 查看栈中保存的列表
  git stash list
 
# 显示栈中其中一条记录
  git stash show stash@{0}
 
# 移除栈中其中一条记录
  git stash drop stash@{0}

# 从栈中检出最新保存的一条记录，并将它从栈中移除（常用）
  git stash pop

# 从git 栈中检出一条记录，但不从栈中移除
  git stash apply stash@{0}

# 从当前栈中最近的一次记录中检出并创建一个分支
  git stash branch branchName
  
# 清空栈里的所有记录
  git stash clear
  

复制代码

7, 面试官必问的两个问题

1，说说git rebase 和 git merge的区别?

说明的rebase,merge的区别进行总结一下即可
复制代码

2，当你在一个分支里做某项功能开发的时候，接到通知生产上有问题，需要紧急修复，但这时你已经在这个分支里加入了其它有问题未提交的代码，这个时候你会怎么操作？

面试官主要是想考一下：对git stash 的了解
复制代码