版本控制

git 记录的是每一次我们的commit记录版本，而不是我们的操作记录。一旦代码发生了reset rebase 或者其他的回滚操作导致commit 记录丢失了。那代码也就丢失了，再也找不回了了。因此我们需要格外的注意代码回滚或者解决冲突时候是否把有用的commit记录给弄丢了

git 的配置

可以全局配置，在每个项目中都使用

git config --global user.name 'sunseekers'
git config --golbal user.email '1390639401@qq.com'
git config --list --golbal // 查看全部config配置

可以局部配置，只对都一个仓库有效

git confif --local user.name 'sunseekers'
git config --local user.email '1390639401@qq.com'
git config --list --local 

优先级 local > global

git merge和git rebase的区别

git merge 是将两个分支合并为一个新的提交。合并分支之后，会生成一个新的合并提交，并且会将两个分支的最新提交进行合并。合并后，历史记录中会出现合并提交，它包含原来两个分支的提交记录。

git rebase 是在一个分支上将另一个分支的更改逐一应用。rebase 命令会将本地的一个分支里的所有提交复制到另一个分支上，同时也会删除所有在这个分支上的修改，让这个分支处理得像刚刚从那个分支上新拉取的一样。它会在新的分支上重新播放这些提交，使得它们似乎是在这个新分支上单独操作的，并且所有提交都是一次性的，最终形成线性提交的历史记录。

merge 会将两个分支的提交历史的内容合并在一起并创建一个合并提交，而 rebase 会将当前分支的基础变成目标分支的最新提交，然后此基础之上完全应用当前分支的所有提交，这样看起来，好像一直在使用当前分支开发，并且没有合并提交。

merge 操作相对比较安全，因为它并不会改变项目内任何一条历史线中的提交，但 rebase 操作可能会产生一连串的冲突，因为它可以修改提交历史线中的提交记录，并且会改变 Git 中的原有提交编号。

merge 能够保留完整的历史记录，而 rebase 会产生简单和线性的历史记录。正确选择哪种方式取决于项目的需求，以及哪种合并方式适合团队工作流程。如果需要保留完整的历史记录，那么建议使用 merge 操作。如果需要提交历史线干净优雅，那么使用 rebase 操作。

git 命令行

git init : 初始化命令

git add . 提交所有的修改的代码放到到暂存区; git add -u: 已经被 git 管理的文件提交到暂存区

git mv oldName newName: git 变更文件名

git commit -m 'feat 新功能': 把暂存区的代码提交到本地分支，此时暂存区没有东西了，清空了

git log: 查看当前分支所有日志， git log --oneline: 在线分支变更记录，git log -n4: 最近的四次 ;git log -n4 --oneline: 最近四次线上的记录； git log --all: 所有分支的提交记录；git log -graph : git 图形化

git branch -v : 查看所有的分支

git status: 查看状态

git diff x y: x的commit 和 y的commit 的差异

git commit --amend: 对最近提交的次commit msg的描述进行变跟，比如commit之后，觉得描述不太对，要重新修改一下，用这个

git commit rebase -i xx: 回到xx的commit，可以使用s进行commit合并，可以是r修改commit msg历史。我们也可以在 rebase 之后，也可以移动commit的顺序

git diff --cached: 暂存区和header之间的差异

git diff : 工作区和暂存区的差异

恢复：变更工作区的内容用 git checkout . 或着 git checkout -- 文件名 ,变更暂存区的用 git reset xx

git rm xx：移除指定文件

git stash --list：查看所有stash里面的东西

git stash apply：stash 里面的东西还在，东西也吐出来了

git stash pop：stash 里面的东西不在了，东西吐出来了

git reset

git reset —hard HEAD: 回到当前的版本，相当于放弃 commit 里面的内容，或者 rebase 的时候，放弃已经 rebase 的部分。 HEAD 表示当前版本，HEAD^ 表示上一个版本 HEAD^^ 表示上上个版本.添加–hard参数后，会回到上次commit的状态，也就是说从上次commit之后的的修改都将被重置，换句话说这些数据都丢失了，所以要谨慎操作哦。因为 git 记录的是版本记录而不是操作记录

git reset —hard xxxx: 回到某一个版本，回滚之后 commit 记录会被删除，会丢失再也找不到了,相当于把所有修改的东西都去掉

git reset xxxx: 回到某一个版本，回滚之后 commit 记录会被删除，回到没有做 git add . 操作的时候

git reset --soft xxxx: 回到某一个版本，回滚之后 commit 记录会被删除，回到刚刚做 git add . 操作的时候

如果强行推送的化（git push -f），之前的记录都会消失没有，如果使用的是git pull –rebase之后git push 之前的记录还在

git revert

撤销某次操作，此操作不会修改原本的提交记录，而是会新增一条提交记录来抵消某次操作，（只是某一次提交回滚了），而git reset会把之前的记录都给删除了（相当于所以之前的提交都没有了，代码也没有了）

git checkout

git checkout -b dev : 创建 dev 分支，然后切换到 dev 分支

git checkout - : 最近切换的两个分支来回切换

git branch -d dev: 删除 dev 分支

git push origin dev: 把本地分支 dev 推送到远程分支

git branch —set-upstream dev origin dev 本地分支 dev 和远程分支 dev 建立关联

git pull --rebase : 拉取并合并远程的分支，当远程的分支和你当前的分支不是基于同一个 commit 提交的代码的时候，并且出现了代码冲突。你就会被移动到一个基于远程最新的一次 commit 创建的本地基变分支，进行代码合并。在冲突都解决完了，本地的基变分支会被删除了，自动回到当前分支。就是这样的操作流程可以始终保证 git 提交记录的点线图始终是一条线。不出现叉支rebase 的原理

git pull --rebase 相当于两个命令的合并 git fetch origin 和 git merge origin/master。当我们开发新版本上线的时候通常会做每一天做 ` rebase master 是为了和 master 代码尽量保持代码分支线在一条直线上，同时又可以避免上线的时候很多问题冲突。[深入 git rebase 使用](https://baijiahao.baidu.com/s?id=1633418495146592435&wfr=spider&for=pc) ，如果 rebase master 之后所有提交记录的时间线都变了，commit` 会发生变化

每天 git rebase master 的代码分支线

没有 git rebase master 的代码分支线

git log --graph git 记录图形化显示 git reflog 和git log的区别

git reflog 可以查看所有分支的所有操作记录（包括（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录，而且跟进结果可以回退道某一个修改

使用git reflog 结合 git cherry-pick可以把已经被删除的commit 给找到，并且进行操作

最好使用 git pull --rebase --autostash (gupa): autostash 把本地没有提交的代码自动缓存起来，避免 rebase 代码的时候失败报错

git rebase —abort: 终止 rebase 代码

git rebase —continue: 继续下一个文件的 rebase

git rebase —skip: 跳过当前基变文件的的 rebase

git rebase —i xxx: 回到某一个 commit（必须提前一个） ,可以对这个 commit 之后的 commit 进行操作，具体的看文档 squash=> 把几个 commit 变成一个提交，提交信息保留; fixup=> 把几个 commit 变成一个提交,提交信息不保留（直接修改 pick 为对应的单词

git cherry-pick xx: 提取其他分支的 xx 提交到当前分支

git stash: 在未执行 add 操作之前，把当前分支的代码临时保存起来，保存起来之后，可以跨分支写新的代码。当你想把 stash 里面的内容取出来的时候执行

git stash pop 就好了，你在哪一个分支执行这个命令，你存在 stash 里面的代码就会吐出到当前的分支。=> 适用于在多分支开发，代码不想丢弃也不想 push 到远程的时候用

rebase 最新的 master 分支

 // 切到master分支
git checkout master or gcm

// 拉取最新master代码
git pull --rebase --autostash or gupa

// 再切到当前开发的分支
git checkout feature/xxx or gco feature/xxx

// rebase master
git rebase master or grbm

// 如果rebase 产生冲突，手动解决冲突，然后
git add . or ga .
git rebase --continue or grbc

// rebase 完之后
git push or gp

// 注意：当 rebase 过程中需要解决冲突
// 在 rebase 完成之后
// git push 无效后 需要用下面的命令
// !!! 用这个命令前 一定要确保本地代码跟线上代码的同步
// git pull --rebase 再一次
git push --force-with-lease or gpf

查看工作区和暂存区的状态 git status

git submodule 子模块

有种情况我们经常会遇到：某个工作中的项目需要包含并使用另一个项目。也许是第三方库，或者你独立开发的，用于多个父项目的库。现在问题来了：你想要把它们当做两个独立的项目，同时又想在一个项目中使用另一个。如果将另外一个项目中的代码复制到自己的项目中，那么你做的任何自定义修改都会使合并上游的改动变得困难。Git 通过子模块来解决这个问题，允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。

# 在主项目中添加子项目，URL 为子模块的路径，path 为该子模块存储的目录路径
git submodule add [URL] [Path]

# 克隆含有子项目的主项目
git clone [URL]
# 当你在克隆这样的项目时，默认会包含该子项目的目录，但该目录中还没有任何文件
# 初始化本地配置文件
git submodule init
# 从当前项目中抓取所有数据并检出父项目中列出的合适的提交
git submodule update
# 等价于 git submodule init && git submodule update
git submodule update --init

# 自动初始化并更新仓库中的每一个子模块， 包括可能存在的嵌套子模块
git clone --recurse-submodules [URL]