git使用（自用记录）

git解决冲突

在本地开发分支与合并目标分支起冲突：

git fetch
git merge origin/ywy/master
注意区分push时候的 origin ywy/master

git fetch的实际操作：建立一系列的本地分支缓存远程分支
可以用git status证实

a1ced026..a630cf18  release/20210831           -> origin/release/20210831

所以我们在本地merge代码时候，其实是在合并两个本地分支
git merge origin ywy/master

补充除了pull、push、fetch是在和远程交互，其他时候其实本地和远程是分开的！
git checkout -b feat/ywy-61 origin/ywy/master

cherry-pick 一个commit提交到多个分支

git checkout -b develop
// 完成一个功能commit一次
git log 
git checkout 目标分支2
// 没有目标分支的push权限，先从目标分支上拉一个分支
git checkout -b new
git cherry-pick commitHASH
注意：git cherry-pick commit1..commit100（左开右闭的操作，commit1不会被操作）

git log 显示从最近到最远的提交日志，查看每次commit的hash标记
git log 看不出来被删除的commitid
git reflog 则可以看到被删除的commitid

submodule

多个repo协同开发
别人维护的模块，在git中使用子模块的功能能够大大提高开发效率。
使用子模块后，不必负责子模块的维护，只需要在必要的时候(e.g:升包之前)同步更新子模块即可。
git submodule init
git submodule update

.gitmodules在仓库中，有版本控制，修改之后会同步到其他仓库，使用submodule相关命令的时候会自动更新
.git/config在本地，需要手动更新，或者执行git submodule sync将新的配置从.gitmodules拷贝到.git/config
git submodule sync会将submodule远程的 url 配置设置到.gitmodules，并且只会影响.git/config已经有 url 的条目，指定–recursive，将会递归更新注册的submodule

.gitmodules文件：

[submodule "packages/模块名"]
	path = packages/模块名
	url = ../../模块名.git

两个路径一个远程，一个本地

工作区、暂存区、版本库、远程仓库

git add：工作区 ——> 暂存区
git commit：暂存区 ——>版本库
git push：版本库 ——>远程仓库

git status 看暂存区，当前工作树处于刚刚完成提交的最新状态，所以结果显示没有更改。

git log 提交日志—graph也可以查看分支

版本回退

git commit -m head
回退一步：

git reset --hard HEAD^

追踪关系

建立起追踪关系之后，push、pull不需要指定远程分支

git branch -a 查看链接的远程库情况
*表示本地主机的当前分支
下一行是远程分支？在本地的缓存？

在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系（tracking）。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系

将某个分支推送到远程仓库上，就能将本地库的内容推送到远程仓库。加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。下一次直接使用 git pull 或者git push.

手动建立追踪关系 git branch --set-upstream origin master
git pull <远程主机名> <远程分支名>:<本地分支名> 如果当前分支与远程分支存在追踪关系，可以省略远程分支名。
取回远程主机的更新以后，可以在它的基础上，使用git checkout命令创建一个新的分支
git checkout -b newBrach origin/master

关于分支

git branch 看分支

git checkout -b 分支名 创建新分支，并将设置为当前分支
等同：
git branch 分支名 创
git checkout 分支名 切换

补充

git
本地上就有三个版本：实际文件、git add . 缓存区域、git commit -m head(最近一次提交)
远程仓库
git remote remove origin
git remote add origin
git remote add origin https://github.com/*.git

创建命令别名
git config --global alias.st status

Git 提供了两种补丁方案，需要进行代码迁移，就可以使用补丁，方便又快捷。
通过 git diff 生成的 .diff 文件： 生成的文件不含有 commit 信息，可以指定文件生成 diff，也可以指定单个 commit， 多个 commit 生成 。
通过 git format-patch 生成的 .patch 文件：含有 commmit 信息。一个 commit 对应一个 patch 文件。

git reset、revert

git reset
首先使用 git log 查看本地提交记录，再使用 git reset < version > 回退到指定版本
使用 git reset 回到前一个版本未提交状态
使用 git reset --hard 回到前一个版本已提交状态，同时删除在这之后的所有提交commit

执行 git reset 后，本地分支版本会落后远程分支版本，如果有代码修改和提交，那么 push 将会失败，git 提醒先 pull 再提交，此时大概率会出现冲突（时刻记住本地操作永远是本地）

git revert
回退版本，并作为一次新的提交增加在 git tree 上，不影响历史 commit 和代码

git revert 在 分支 merge 中使用会出现问题，所以要慎用
在主分支和次分支同时进行代码修正，那么在提交时，两个分支的内容是不同的，也就是"分叉"了

git rebase 衍合

第一种方法会造成 git tree 中有大量 merge commit，观感比较丑

第二种方法相对清爽，执行 git rebase 命令则先将本地分支的修改抽离出来作为补丁(patch)，然后将本地分支更新到远程分支，最后再将补丁应用到本地分支上

执行 git rebase 时若出现代码冲突，那么解决后再 git rebalse continue 可以继续执行

衍生命令：

git rebase -i 合并请求 => git rebase HEAD~2

git log --graph --abbrev-commit --decorate --all --oneline 以时间线的形式展示 git tree

merge 、rebase

merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容，提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面。
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面，提交历史反映了项目过程中发生了什么，关注点在开发过程上面。
merge 与 rebase 都是非常强大的分支整合命令，没有优劣之分，使用哪一个应由项目和团队的开发需求决定