使用git的几个经验分享

使用git的几个经验分享

1. git 中的”后悔药” git reset

日常开发中，难免会有在提交记录上来回切换的需求：比如希望回到上一个版本状态，此时git reset命令可以轻松实现版本回退

现在新建一个文件用于操作演示

# 初始化版本库
> git init 
# 添加文件，加入一行文字： hello world,this is first commit
> vim readme.text
# 添加到暂存区，然后commit
> git add -A .  // 为了省事儿，添加所有工作区目录内文件到暂存区
> git commit -m "first commit"
# 再添加一行内容：second commit ,git is free software,并重复上述提交步骤
> git commit -m "second commit"

使用log命令查看提交历史信息

> git log
commit 5627d32d8b8283dee4d78b68763b89f86a7fcdef (HEAD -> master)
Author: sunhongmin <wb-shm672043>
Date:   Thu Apr 29 09:53:35 2021 +0800

    second commit

commit e68f93aefd091794db2a3a53d9f1cc2f32ae876f
Author: sunhongmin <wb-shm672043>
Date:   Thu Apr 29 09:48:53 2021 +0800

    first commit

现在实现一个简单需求：丢弃掉第二次提交，将工作区恢复到第一次提交后的状态

# 使用git reset --hard 命令，加入第一次提交的commitId，表示将版本回退到第一次提交
> git reset --hard e68f93aefd091794db2a3a53d9f1cc2f32ae876f
HEAD 现在位于 e68f93a first commit

好了，现在轻松实现了版本回退的需求，现在问题来了，如果我后悔了怎么办

第二个需求：回滚刚才的操作，将工作区恢复到reset之前的状态

# 善用git reglog命令，它能展示出你所有的git操作
> git reglog
e68f93a (HEAD -> master) HEAD@{0}: reset: moving to e68f93aefd091794db2a3a53d9f1cc2f32ae876f
5627d32 HEAD@{1}: commit: second commit
e68f93a (HEAD -> master) HEAD@{2}: commit (initial): first commit

可以看到，我在两次commit操作之后，执行了reset操作

每次操作，都会有对应的commitId (是的，并不是commit才会有commitId)

现在来回滚吧

# 有了commitId 加上reset ，可以帮助你随时恢复到任何一个操作状态，当然如果没有add或者commit，那就是另一种情况了
> git reset --hard 5627d32
HEAD 现在位于 5627d32 second commit
# 可以看到已经回滚到second commit了，强烈建议牢记reset命令

我们已经了解，git reflog命令，可以查看commit及reset操作，其实，git reflog可以将分支合并操作（例如你pull下代码之后，将远程分支内容与本地分支内容合并）、分支切换操作都展示出来

一点经验：区分哪种场景使用 git log 哪种场景使用git reflog:

日常使用中，git reflog常常用于紧急情况，因为近期的操作记忆比较清晰，所以结合git reset可以应对回退、恢复等操作

而git log因为是单分支并且带有commit内容，所以日常版本回退等操作会经常用到。

拓展点： git reset命令，除了–hard外，还有–soft以及–mixed参数，可根据实际情况进行选择，语法如下：

git reset [ --mixed | --soft | --hard] commitId

1. 使用参数–mixed(默认参数)，如git reset --mixed commitId 或git reset
   撤销git commit，撤销git add，保留编辑器改动代码
2. 使用参数–soft，如git reset --soft commitId
   撤销git commit，不撤销git add，保留编辑器改动代码
3. 使用参数–hard，如git reset --hard commitId ——此方式非常暴力，全部撤销，慎用
   撤销git commit，撤销git add，删除编辑器改动代码

2. git 中的“回收站“：git stash

相信你遇到过这样的情况：专业的你每次提交都保证功能的完整性，以防将来某一时刻版本回退时出现功能不完整的尴尬场面，某一天你正在专心的写features，突然老大ding你，让你切换到xxx分支修复紧急线上BUG，一边是写到一半的功能，**但你又不想commit（因为代码不完整，或者部分测试代码不能提交以防不小心push到线上出现严重安全问题）**一边是紧急的bug，怎样将当前工作状态放到一个临时的目录下呢？

git stash 是git提供的一个独立的存储栈结构目录，你可以随时将未提交的工作区文件状态记录进去，以便将来某一时刻进行恢复

假设我想要写一段代码到刚才的readme.text文件

> vim readme.text
hello world,this is first commit
second commit ,git is free software
const uniqueUserList = userList.filter(function(element,index,self){
		//TODO 数组去重逻辑
});
## 刚写一半，不得不去另一个分支改BUG
> git stash save "distinct userlist features"
保存工作目录和索引状态 On master: distinct userlist features
## 查看一下当前stash里边存储的记录
> git stash list
stash@{0}: On master: distinct userlist features

好的，现在查看下工作区的readm.text发现刚刚写的代码已经消失了

> vim readme.text
hello world,this is first commit
second commit ,git is free software
#查看下git当前的状态
> git status
位于分支 master
无文件要提交，干净的工作区
## 现在工作区未提交的内容已经被stash保存了，此时可以放心切换其他分支

当你在其他分支完成工作之后，切回来时想要恢复刚才的暂存状态，使用git statsh pop或者git stash apply

# pop 与 apply 都可以将位于栈顶的记录恢复到工作区，只是pop 操作会同时删除掉弹出的记录，为了演示先用apply
> git stash apply
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
	修改：     readme.text

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

## 再查看下readme.text文件
> vim readme.text
hello world,this is first commit
second commit ,git is free software
const uniqueUserList = userList.filter(function(element,index,self){
    //TODO 数组去重逻辑
});

## 可以看到工作区已经恢复当时的状态，此时可以继续完成后边的工作

此时再次查看stash list

> git stash list
stash@{0}: On master: distinct userlist features

# 可以看到，刚刚恢复的记录仍然被保留，如果使用了pop参数，那么该记录在恢复的同时stash记录会被清理
> git stash pop
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
	修改：     readme.text

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）
丢弃了 refs/stash@{0}（66dfa4049b8f65713408108b02c92906365f9324）
> git stash list
# 可以看到记录在被恢复的同时，stash记录被丢弃

**git stash pop**不光可以将暂存的记录恢复到当前分支，也可以切换到其他分支上，将更改恢复到其他的分支上，所以，stash 记录是全局的。

3. git rebase 与 git merge

同样作为分支合并的命令，这里说下我的理解

现基于master当前第二个提交为基础拉出两个新分支base_by_master_branch_1、base_by_master_branch_2

> git branch base_by_master_branch_1
> git branch base_by_master_branch_2
> git branch
  base_by_master_branch_1
  base_by_master_branch_2
* master

现在切换到两个分支上分别做一次提交

# base_by_master_branch_1
> git commit -m "逻辑实现"
[base_by_master_branch_1 38b3802] 逻辑实现
 1 file changed, 3 insertions(+)
# base_by_master_branch_2
> git commit -m "逻辑实现"
[base_by_master_branch_2 eb5c17c] 逻辑实现
 1 file changed, 3 insertions(+) 

现在假设master上有了新的提交

# master
# 为了不在合并时造成冲突，在第一行新增了内容：Git has a mutable index called stage.
> vim readme.text
hello world,this is first commit, Git has a mutable index called stage.
second commit ,git is free software
# 对变更做一个提交
# 查看master提交记录
> git log --pretty=oneline
686c247212133df340053a8f534a6fb5db9e6176 (HEAD -> master) add new text
5627d32d8b8283dee4d78b68763b89f86a7fcdef second commit
e68f93aefd091794db2a3a53d9f1cc2f32ae876f first commit

现在master分支上在第一行增加了一段文字，其余两个分支做了相同的“逻辑实现”的提交，现在分别用rebase以及merge，来查看效果

# branch_1使用merge 合并master
> git merge master
> git log --graph --pretty=oneline --abbrev-commit
*   d99affb (HEAD -> base_by_master_branch_1) Merge branch 'master' into base_by_master_branch_1
|\  
| * 686c247 (master) add new text
* | 38b3802 逻辑实现
|/  
* 5627d32 second commit
* e68f93a first commit

# branch_1使用rebase 合并master
> git rebase master
> git log --graph --pretty=oneline --abbrev-commit
* 87c513a (HEAD -> base_by_master_branch_2) 逻辑实现
* 686c247 (master) add new text
* 5627d32 second commit
* e68f93a first commit
# master 提交位于分支提交之后

rebase 是变更分支基础的操作，当你基于的base分支有了更新，你可以使用rebase将你的提交重新基于base最新的状态，这样做的好处就是，把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了

merge操作则会保留两个分支的提交信息，并且分支合并的操作也被记录，为了安全起见，只有独立分支完全由你自己开发时，才可以考虑rebase来使提交记录变得简洁，其余情况，最好使用merge。

4. git cherry-pick

转移一次或一系列提交至另一个分支上，git界的ctrl+c ctrl+v，赶快学起来
感觉我峰哥写的够清晰了，改日我再整理
传送门

完~