git rebase和add -p和git pull --rebase记录

几个自己不太熟练的细节记录。

1. git pull

git pull
就是你的代码落后了真实的提交很多了，而你却在这个老一点的分支，准备commit。这个时候，你想起来，要拉一下代码了。于是一拉，就被merge到了本地。
就会产生的提交

Merge branch 'master' xxxxxx

并且，git log --graph也变的不连续。
git pull --rebase
这个时候，我们就应该用上面代码替代。而且现在git新版本会推荐你默认pull带rebase。
第一次使用git时会提示，或者手动配置~/.gitconfig如下：

[pull]
    rebase = true

在执行git pull --rebase（或者有上述config的时候git pull等价于git pull --rebase）。
粗暴的理解就是，他会帮你优先将远程的commits全部先合并到本地，并将你的commit搞到最新，如果有冲突就提示你解决冲突，并合并再提交。
这样，就相当于你已经到了最新代码下再commit的代码了。就不会产生merge branch的commit或者分叉的graph了。

因此，大部分公司都会要求提交代码前，一定要git pull --rebase：
我提出一个原则：提交代码之前，必须要基于最新的远程代码提交。
仔细理解这句话的含义就知道：
不得在没有确认是基于最新代码提交的时候，不得push。
几个好处：

1. 减少上述的merge commit和graph的分叉；
2. 目的就是保证在最新的远程代码上提交。避免你的开发，与别人的已经开发过代码冲突。

2. git rebase

rebase主要有如下2种使用场景：

切分支开发与合并分支

#你在本地local分支（并没有远程对应,纯粹是本地开发使用），切回主分支，更新master
git checkout master 
#更新master代码
git pull
#切回去
git checkout local

#关键的来了，这个时候，把代码变基到最新的上面。
git rebase master  ---->解决冲突--->git rebase --continue
# 搞完以后，切回主分支
git checkout master
# 把local的改动，全部合并到master这边来
git merge local
#提交
git push

这里我不得不吐槽下。如上操作的难度下，但是99%的攻略人都很喜爱。为什么？因为它完全遵循了git的标准规范来开发代码。对于已经掌握的人而言确实难度不高。
但是复杂度很大，又要开分支，又要切来切去pull，rebase，又要merge的。
联系到前面讲的pull --rebase。

我们就知道区别了：
pull --rebase是为了直接将远程的代码与本地（因为你就在远程分支下开发的）整合；而rebase的一套操作是为了本地额外分支与远程分支的，整合。

无可厚非，开分支开发，最后rebase，merge的整套操作。它十分规范，但是我就是不喜欢。那么怎么做呢？我建议空间换复杂度:

1. 直接在要开发的远程分支上开发。不用在本地拉出额外的；
2. 在另外的目录拉一个代码，永远不要动他，只做git pull，来保证与远程一模一样；
3. 提交前，去隔壁pull下看看，git log对比省察下，是不是基于最新的去提交的，不是的话，git pull --rebase拉下，解决冲突。再提交即可；
4. 有的时候冲突不好解决，因为vim下很难看明白，这个时候空间换复杂度就体现了，我们直接bcompare比较，轻松理解别人的改动跟你本地的改动冲突的原因。解决好了以后git add .并continue。

合并commit

commit c2b7e9021f6516ad46cfdb8f41bab0aaa825a023 (HEAD -> work)
Date:   Wed Aug 18 14:57:29 2021 +0800
    2次修改newfile

commit 319454f20c3bace710850509027688b6f1c66a24
Date:   Wed Aug 18 14:57:11 2021 +0800
    修改read

commit b2882774462d1ebcec7de4f49a568f3503ed8c9e
Date:   Wed Aug 18 14:56:48 2021 +0800
    first提交newfile

commit 70a5827e833ae3102399b7cd8efe14cd5d01a5e8 (origin/master, origin/HEAD, master)

1. 合并多个commit 我想将3个合并成一个commit？
   git rebase -i HEAD~3
   将后面2个改成s(squash)，将会自动合并；
   等价于：
   git reset 到前面第4个commitId，
   再重新git add . 然后 git commit -m "xxx"

2. 我想将最新的commit和前前一个合并， 比如我这里2个修改newfile中间隔了一个别的提交，我想将改动newfile的合并，但是想让中间修改别的保留commit：
   git rebase -i 70a5827e833ae3102399b7cd8efe14cd5d01a5e8 第一步，指定rebase到3个之前的commitId；
   这个时候在弹出的编辑中，修改顺序（git真牛！还可以改顺序！），

pick 379cba6 first修改newfile
pick 819ebae READ   ==》 改动到最前面或者最下面
pick f7a2485 二次修改newfile =》 pick改成s

改动后：

pick 379cba6 first修改newfile
s f7a2485 二次修改newfile
pick 819ebae READ

:wqa后，二次弹出的，可以编辑一下commit信息。也可以不管继续保存关闭。
最后得到的git log：

commit 5badea2b061429fe6d5a5ccc4782532e5e045e67 (HEAD -> work)
Date:   Wed Aug 18 15:08:40 2021 +0800
    READ

commit 93beb296b393ac51f924103dcb1f923ff500598d
Date:   Wed Aug 18 15:08:33 2021 +0800
    first修改newfile
    二次修改newfile

commit 70a5827e833ae3102399b7cd8efe14cd5d01a5e8 (origin/master, origin/HEAD, master)

3. git add -p

add -p我经常使用

To remove ‘-’ lines, make them ’ ’ lines (context).
To remove ‘+’ lines, delete them.
Lines starting with # will be removed.

一般情况，git会帮你hunk的比较好，这个使用就‘y’确认即可。
但是有的时候，由于2份部分代码太近，无法直接单独处理。如下图2个+号，我希望能分割开来提交。就无法单独分割提交。
这个时候使用‘e’，而不是‘y’：
1. 提交的新增代码+号，直接删除(vim dd)删除+号；
2. 提交的删除代码-号，就删除掉-号，并空格一下。

不用怕操作错误，错误了他不会有任何改变。比如如下会提示损坏。并不会导致代码丢失。