一、上传本地项目到gitLab
1.先记录个人信息
git config --global user.name "xxx"
git config --global user.email "xxx@xxx"
2.上传
// 1. git add : 添加到暂存区
git add xxx文件
git add -A // 添加所有文件（通常改动较多可以直接使用这句命令）
// 2. git commit -m "备注信息"：添加到数据仓储
git commit -m "备注信息" // 添加 -m 选项，将提交信息与命令放在同一行
git commit -a -m "备注信息"// 加上 -a 选项，就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤（但是未经过git add步骤的新增的文件，就不可以，需要先git add）
// 3. git push 推送到远程服务器 gitLab
git push [地址] master
// 推送本地分支到远程
git push origin <分支名>
git status // 显示工作目录和暂存区的状态
// 可以看见，执行 git add 前后的状态对比
二、下载远程服务器的项目到本地
1.将其他仓库克隆到本地
包括被clone仓库的版本变化
git clone <版本库的url>
// HTTPS
git clone https://github.com/tensorflow/tensorflow.git
// SSH
git clone [email protected]:tensorflow/tensorflow.git
// 如果本地目录不想与远程仓库同名:
git clone <版本库的网址> <本地目录名>
2.拉取远程分支更新到本地仓库
比如远程仓库里的学习资料有了新内容，需要把新内容下载下来的时候，就可以使用git pull命令。事实上，git pull是相当于从远程仓库获取最新版本，然后再与本地分支merge（合并）。
即：git pull = git fetch + git merge
注：git fetch不会进行合并，执行后需要手动执行git merge合并，而git pull拉取远程分之后直接与本地分支进行合并。更准确地说，git pull是使用给定的参数运行git fetch，并调用git merge将检索到的分支头合并到当前分支中。
git pull <远程主机名> <远程分支名>:<本地分支名> // 使用
// 举例：将远程主机origin的master分支拉取过来，与本地的 master 分支合并。
git pull origin master
以上的git pull操作如果用git fetch来表示：
git fetch origin master:tmp // 本地新建temp分支，并将远程的master分支下载到temp
git diff tmp // 可以比较本地代码与刚刚从远程下载下来的代码的区别
git merge tmp // 合并temp分支到本地的master分支
git branch -d temp // 最后可删除temp分支
三、本地分支的创建、切换、删除
1.查看分支信息
git branch // 查看本地分支
git branch -r // 查看远程分支
git branch -a // 查看所有分支（本地+远程），只有分支名称
git branch -v -a // 查看所有分支，有分支名称+备注信息
2.新建分支，并切换到新的分支
git checkout -b develop
// 相当于下面两步：
git branch develop // 创建 develop
git checkout develop // 切换到 develop
问：如何切换分支而又不用带上刚刚修改的文件？
在使用 git 的时候，我们往往使用 branch 解决任务切换问题，例如，我们往往会建一个自己的分支去修改和调试代码，如果发现原有的分支上有个不得不修改的 bug，我们往往会把完成一半的代码 commit 提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。这样的话往往 log 上会有大量不必要的记录。
其实如果我们不想提交完成一半或者不完善的代码，但是却不得不去修改一个紧急 Bug，那么使用' git stash ' 命令就可以将你当前未提交到本地（和服务器）的代码推入到 Git 的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修 Bug，等到修完 Bug，提交到服务器上后，再使用 ' git stash apply ' 将以前一半的工作应用回来。
也许有的人会说，那我可不可以多次将未提交的代码压入到栈中？答案是可以的。当你多次使用 'git stash' 命令后，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑。
git stash list // 将当前的 Git 栈信息打印出来
git stash apply stash@{1} // 应用指定版本的工作 stash@{1}
git stash drop stash@{1} // 移除指定版本
git stash clear // 清空栈信息
3.合并分支
3.1 修改文件后，保存修改
git commit -a -m "修改一些细节" // 自动把所有已经跟踪过的文件暂存起来一并提交
3.2 转换到master，合并develop
// 切换到 master分支
git checkout master
// 对 develop 分支进行合并
git merge --no-ff develop // --no-ff 执行正常合并
解释一下 --no-ff 参数。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。
- git merge –no-ff 可以保存你之前的分支历史。能够更好的查看 merge历史，以及branch 状态。
- git merge 则不会显示 feature，只保留单条分支记录
3.3 查看未合并工作的分支
git branch --no-merged
4.删除分支 -d
git branch -d <branchName>
5.修改分支名称
// 5.1 修改本地分支名
git branch -m oldName newName
// 5.2 修改远程分支名 (已经推送远程-假设本地分支和远程对应分支名称相同)
// a. 重命名远程分支对应的本地分支
git branch -m oldName newName
// b. 删除远程分支
git push --delete origin oldName
// c. 上传新命名的本地分支
git push origin newName
// d.把修改后的本地分支与远程分支关联
git branch --set-upstream-to origin/newName
四、远程分支
1.查看远程分支
git branch -r // git branch 是查看本地分支； git branch -a 是查看所有分支
// 要先 git pull 远程的最新信息，才能看到最新的所有远程分支
2.跟踪远程分支
2.1 查看本地分支与远程分支的对应关系
git branch -vv //查看设置的所有跟踪分支，可以使用 git branch 的 -vv 选项。 这会将所有的本地分支列出来并且包含更多的信息，如每一个分支正在跟踪哪个远程分支与本地分支是否是领先、落后或是都有。
git branch -v -a // 显示当前使用仓库的所有分支
git remote show origin // 查看本地分支与远程分支的对应关系
2.2 如果远程新建了一个分支，本地没有该分支，可以用：
git checkout --track origin/branch_name // branch_name 是远程需要跟踪的分支名
2.3 拉取远程分支，并创建本地分支（作用和上面 好像一样）
git checkout -b 本地分支名x origin/远程分支名x
用上面中方法，得到的分支名永远和远程的分支名一样。如果想新建一个本地分支不同名字，同时跟踪一个远程分支可以利用。
git checkout -b new_branch_name branch_name
小结：
git push --set-upstream origin branch_name // 在远程创建一个与本地 branch_name 同名的分支并跟踪
git checkout --track origin/branch_name // 在本地创建一个与远程 branch_name 同名分支跟踪远程分支
从远程分支 checkout 出来的本地分支，称为 跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入 git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来。
也就是说，如果存在跟踪分支 originTest ，在该分支上修改文件，然后直接执行 git push ，那么修改的文件存在远程的 originTest 分支中。
3.删除远程分支
git push origin --delete <远程分支名> // 删除后可以通过 git branch -r 查看所有远程分支
4.根据远程已删除的分支，删除本地还没删除的分支
可以通过命令 git branch –a 用来查看所有的分支，包括本地和远程的。但是有时会发现有些分支在远程早就被删除了，但是本地依然可以看见这些被删除的分支。
可以通过命令，git remote show origin 来查看有关于origin的一些信息，包括分支是否tracking。
refs/remotes/origin/feature/basis-group 过时（使用 'git remote prune' 来移除）
refs/remotes/origin/release/5.1.1 过时（使用 'git remote prune' 来移除）
develop 推送至 develop (最新)
master 推送至 master (最新)
此时删除本地过时的分支：git remote prune origin
git remote prune origin
> [已删除] origin/feature/basis-group
> [已删除] origin/release/5.1.1
五、临时（feature, release, hotfix）分支
1.概念
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
- 功能（feature）分支
- 预发布（release）分支
- 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后应该删除，使得代码库的常设分支始终只有Master和Develop。
2.功能分支 feature
是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。功能分支的名字，可以采用 feature-* 的形式命名。
3.预发布 release
我们最初所有的开发工作都在 develop 分支上，当我们这一期的功能开发完毕的时候，我们基于 develop 分支开一个新的 release 分支。这个时候我们就可以对 release 分支做统一的测试了，另外做一些发布准备工作：比如版本号之类的。
如果测试工作或者发布准备工作和具体的开发工作由不同人来做，比如国内的 RD 和 QA，这个 RD 就可以继续基于 develop 分支继续开发了。再或者说公司对于发布有严格的时间控制，开发工作提前并且完美的完成了，这个时候我们就可以在 develop 分支上继续我们下一期的开发了。同时如果测试有问题的话，我们将直接在 release 分支上修改，然后将修改合并到 develop 分支上。
待所有的测试和准备工作做完之后，我们就可以将 release 分支合并到 master 分支上，并进行发布了。
4.紧急修复 hotfix
顾名思义，hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 master 分支开一个 hotfix 分支，修复 bug 之后再将 hotfix 分支合并到 master 分支并进行发布，同时 develop 分支作为最新最全的代码分支，hotfix 分支也需要合并到 develop 分支上去。仔细想一想，其实 hotfix 分支和 release 分支功能类似。hotfix 的好处是不打断 develop 分支正常进行，同时对于现实代码的修复貌似也没有更好的方法了（总不能直接修改 master 代码吧:D）。
注意：如果在拉 feature 时，别人有个release在测试，那么先别开feature。因为两者都是根据develop拉下来的，如果别人release没通过，而我的feature通过测试，后面上线后就包含了之前release没通过的代码。解决方法：应该自己拉 hotfix，验收后MR时，标题前加上“WIP”（避免 MR 在准备就绪前被合并），在确认可以合并后，则编辑工单来手动删除WIP。
六、pull、rebase、merge
当你在专用分支上开发新 feature 时，然后另一个团队成员在 master 分支提交了新的 commits，这会发生什么？这会导致分叉的历史记录，对于这个问题，使用 Git 作为协作工具的任何人来说都应该很熟悉。
整体概括：
git fetch // 从远程下载到本地；若需要合并还需要 merge 合并。
git pull // 从远程下载到本地，并合并到当前分支
git rebase // 在新基准的基础上，将本地基于旧基准的commits再做一遍
1.git pull
git pull：从远程获取当前分支的最新更改，并将这些更改应用于分支的本地副本。通常，这是通过合并完成的，即将本地更改合并到远程更改中。因此 git pull = git fetch & git merge
git pull 和 git pull --rebase 区别：git pull做了两个操作分别是 获取 和 合并。所以加了rebase就是以rebase的方式进行合并分支，默认为merge。
2.git rebase
git rebase 解决了和 git merge 同样的问题。这两个命令都旨在将更改从一个分支合并到另一个分支，但二者的合并方式却有很大的不同。
可以使用以下命令将 master 分支合并到 feature分支上：
git checkout feature // 切换到 feature 分支
git rebase master // 合并 master 分支
这里补充一点：rebase 做了什么操作呢？
- 首先，git 会把 feature 分支里面的每个 commit 取消掉；
- 其次，把上面的操作临时保存成 patch（补丁） 文件，存在 .git/rebase 目录下；
- 然后，把 feature1 分支更新到最新的 master 分支；
- 最后，把上面保存的 patch 文件应用到 feature1 分支上。
将整个 feature 分支移动到 master 分支的顶端，从而有效地整合了所有 master 分支上的提交。但是，与 merge 提交方式不同，rebase 通过为原始分支中的每个提交创建全新的 commits 来 重写 项目历史记录。
在rebase的过程中，有时也会有conflict，这时Git会停止 rebase 并让用户去解决冲突，解决完冲突后，用 git add 命令去更新这些内容，然后不用执行git-commit，直接执行 git rebase --continue ，这样 git会继续应用余下的补丁。
在任何时候，都可以用 git rebase --abort 参数来终止rebase的行动，并且 feature1 分支会回到rebase开始前的状态。
3.git merge
最简单的方式是通过以下命令将 master 分支合并到 feature 分支中：
git checkout feature
git merge master
// 后缀 --no-f ：如果不加 --no-ff 则被合并的分支之前的commit都会被抹去，只会保留一个解决冲突后的 merge commit；加了就会保留
或者，你可以将其浓缩为一行命令：
git merge feature master
这会在 feature 分支中创建一个新的 merge commit，它将两个分支的历史联系在一起，请看如下所示的分支结构：
使用 merge 是很好的方式，因为它是一种 非破坏性的 操作。现有分支不会以任何方式被更改。这避免了 rebase 操作所产生的潜在缺陷。
另一方面，这也意味着 feature 分支每次需要合并上游更改时，它都将产生一个额外的合并提交。如果master 提交非常活跃，这可能会严重污染你的 feature 分支历史记录。尽管可以使用高级选项 git log 缓解此问题，但它可能使其他开发人员难以理解项目的历史记录。
4. 整体流程：
1. 前提：远程上线，本地需要更新
2. 本地拉取最新master和develop
git pull <远程主机名> <远程分支名>:<本地分支名>
git pull origin master:master
git pull origin develop:develop
3. 切换到自己的开发分支，rebase 分支 develop / master
git rebase develop
4. 顺利的话就会直接完成，有冲突的话就需要依个解决冲突
4.1 当遇到冲突
依次解决冲突后，使用：
git add/rm <conflicted_files> // 添加进暂存区或删除文件
git rebase --continue // 继续执行 rebase
5. 完成rebase后，继续开发。然后执行git push -f origin feature/add-activeIndex 把本地分支覆盖远程分支
6.介绍一下 git rm
- git rm： 来删除文件，同时还会将这个删除操作记录下来;
- rm： 来删除文件，仅仅是删除了物理文件，没有将其从 git 的记录中剔除;
提示：即使你已经通过 rm 将某个文件删除掉了，也可以再通过 git rm 命令重新将该文件从 git 的记录中删除掉。
注意：上述操作最后要执行git commit才真正提交到git仓库
- git rm ： 同时从工作区和索引中删除文件。即本地的文件也被删除了。
- git rm --cached ： 从索引中删除文件。但是本地文件还存在， 只是不希望这个文件被版本控制。
七、查看仓库的历史记录
1.git log
git log // 显示仓库中每个 commit 的详细提交信息
--oneline // 每行显示一个 commit；显示 commit 的 SHA 的前 7 个字符；显示 commit 的备注消息
--graph // 开启了拓扑图选项
--reverse // 逆向显示所有日志
--stat // 显示被修改的文件；显示添加/删除的行数；显示一个摘要，其中包含修改/删除的总文件数和总行数
--patch // 简写为 -p；显示具体的修改
-n // 显示n条
// 这些选项可多选
git log SHA // SHA 是某一个commit的哈希值；查看特定的commit
// 常用
git log --oneline -5 // 只需要看前几条记录的情况下
太多log记录时，可以按回车键查看下一个，可以按 q 退出查看
2.git show
git show SHA // 显示特定的提交信息
// 与 git log SHA 的区别：
git log SHA：并不会单独的显示某个提交，而是输出这条数据从最开始到最新状态的历史记录（commit头信息、作者、日期、commit备注消息）
git show SHA：显示commit头信息、作者、日期、commit备注消息、具体文件差异
八、版本回退 git reset
1.介绍
实际操作时，每当觉得文件修改到一定程度时，就可以“保存一个快照” commit 。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。具体操作：1.查看历史提交记录（ git log ）；2.回退到指定的 commit。
git reset HEAD^ // 回退到上一版本
git reset HEAD～1 // 回退到上一版本
git reset HEAD～100 // 回退到前100个版本
如果从版本 1.1.5 回到 1.1.0，但是还想再回去 1.1.5 ，那么就找到之前git log 的信息，找到该版本的 commit SHA，就可以 git reset SHA 回去。如果找不到之前的信息了，则可以通过命令 git reflog 查找。（git reflog 是记录每一次命令的）
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把 HEAD 指向改变了而已。reset做的事就是：重置HEAD(当前分支的版本顶端）到另外一个commit，这不会产生commits，仅仅更新一个branch。
2.参数
2.1 --soft
- git reset --soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可； // 也就是：只有最新的commit操作被撤销，但代码没有撤销；如果还想要再次提交，再次 commit 即可。
2.2 --hard
- git reset --hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容，撤销的commit中所包含的更改被冲掉；
3.其他 git revert
git revert // 创建一个commit来覆盖当前的commit，指针向后移动
区别：
- git revert 是撤销某次操作，此次操作之前的commit都会被保留
- git reset 是撤销某次提交，但是此次之后的修改都会被退回到暂存区
九、远程仓库 git remote
1.查看远程仓库
git remote // 显示远程仓库名称 origin
git remote -v // 显示需要读写远程仓库使用的 Git 保存的简写与其对应的 URL
// origin [email protected]:liyapei/todolist.git (fetch) // 读
// origin [email protected]:liyapei/todolist.git (push) // 写
2.添加远程仓库
git remote add <shortname> <url> // git remote add vuecli https://github.com/Allison-LYP/vuecli3-project.git
3.远程仓库的重命名、移除、修改地址
3.1 重命名
git remote rename <oldName> <newName> // 1.重命名
// git remote rename vuecli vc 注意：这同样也会修改你的远程分支名字。 那些过去引用 vuecli/master 的现在会引用 vc/master
3.2 移除远程仓库
git remote rm <远程仓库名> // 2.移除
3.3 修改远程仓库地址
git remote set-url <远程仓库名> url // 3.修改远程仓库地址(修改完通过 git remote -v 查看改变了)
// git remote set-url vc https://github.com/Allison-LYP/vuecli3-project.git
十、标签 git tag
1.打标签
首先，先转换到需要打标签的分支上（ git checkout），完成相关的 commit 操作后，再打标签。
git tag // 查看所有标签
1.1 打一个新标签
git tag -a 标签名 -m "附注信息" // 命名格式
// git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h"
1.2 想给之前的某一个 commit 打标签
git tag -a 标签名 -m "附注信息" commitID
// git tag -a v0.1 -m "version 0.1 released" 1094adb
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
1.3 打标签遵循语义化版本控制规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改（大型的业务变动，或者技术架构改动）
- 次版本号：当你做了向下兼容的功能性新增（增加新功能、性能升级，或者重构原有某部分功能）
- 修订号：当你做了向下兼容的问题修正（业务小改动，或者 Bug 修复等）
2.将tag推送至远程仓库
git push origin --tags
如果刚刚同步上去，就发现了一个致命bug，需要重新打版本：
2.1 删除标签
git tag -d 标签名 // 1.只删除了本地的tag
git push origin :refs/tags/标签名 // 推送空的同名版本到线下，达到删除线上版本的目标
// 这时本地和远程的已经全部删除
3. 查看标签信息
git tag -ln // 显示所有 tag 及其 commit 信息
git show v1.0 // 回滚版本时，我们需要根据标签名查找相应的commit提交信息。git show 标签名会列出指定的标签信息，及详细的提交信息
4.获取远程版本
git fetch origin tag <tagName>
十一、补丁 git format-patch
应用场景：
有两个git库（同一个git库不同分支可以用cherry-pick），两个git库代码是相关联的，要有选择的定期将其中一个git库的修改merge到另外一个库中。（把库A的一部分代码生成补丁，在库B里打入）
Git 提供了两种补丁方案，一是用git diff生成的UNIX标准补丁.diff文件，二是git format-patch生成的Git专用.patch 文件。
- 通过 git diff 生成的文件不含有 commit 信息，可以指定文件生成 diff，也可以指定单个 commit， 多个 commit 生成 。
- 通过 git format-patch 生成的 .patch 文件 含有 commmit 信息。一个 commit 对应一个 patch 文件。
1.打补丁
1.1 某次提交（含）之前的几次提交（往下算）
git format-patch <commit id> -n // n指从 commit id 对应的 commit 开始算起的 n 个提交
// eg: git format-patch da39747 -1 : da39747 本身
// eg: git format-patch da39747 -2 : 包含 da39747 的之前的2次提交（即 da39747 本身 + 他的前一个）
1.2 从某 commit 以来的修改（不包含该 commit ）（往上算）
git format-patch <commit id>
1.3 某两次 commit 之间的所有 patch
git format-patch <commit id1> .. <commit id2>
1.4 获取 commit id
git log --oneline
2.把补丁拷贝到目标git的目录下（库B）
即 补丁打完后，将其放到需要放到的项目目录下。可以在项目下建一个 patch 文件夹，放置需要的 .patch 文件
3.测试patch
3.1 检查patch文件
git apply --stat <patch文件名>
3.2 检查是否能应用成功
git apply --check <patch文件名> // 没显示文字，就说明可用，且无冲突
3.3 打入patch
在使用git am之前， 你要首先git am --abort 一次，来终止以前的am信息，这样才可以进行一次全新的am
git am --s < xxx.patch // 使用--s或--signoff选项，可以commit信息中加入Signed-off-by信息
// 可以批量，也可以单个
// git am ~/patch/patch/*.patch patch文件放在这个路径下
4.冲突解决
当我们打补丁出现冲突的时候，这个时候需要我们手动解决冲突。
4.1 首先，执行以下命令，自动合入 patch 中不冲突的代码，同时保留冲突的部分
git apply --reject xxxx.patch // 会生成后缀为 .rej 的文件，保存没有合并进去的部分的内容
4.2 解决完冲突后删除后缀为 .rej 的文件，并执行 git add 添加改动到暂存区
第三步： 执行 git am --resolved 或者git am --continue ，最后 push 上去。
5.如何制作与使用PATCH
PATCH是指在ci编译时用到的一个环境变量，变量名为$AG_PATCH，ci执行编译前会先应用该变量的内容。ci中关于PATCH的操作详见项目中的.gitlab-ci.yml文件，搜索$AG_PATCH。PATCH的内容放在项目git页面 -> 设置 -> CI/CD -> 环境变量。点击下方的展示按钮即可在"AG_PATCH"项的右侧看到patch的内容，更改内容后点击下方的保存按钮即可保存。
(1）何时适合用打PATCH的方式上线
- 需要快速上线时。例如突发的bug，可以通过打PATCH紧急修复上线。
- 临时性的改动，或短时间需要多次改动的地方。例如某个功能上线但暂时不开放、因某个活动开展需要网站进行调整、需要接入用于测试的数据分析产品。
(2)开发人员打PATCH的步骤
- 切换本地git项目的分支为master
- 确保master为最新。并确保当前工作区是干净的，无任何文件被修改，有修改的先用git stash暂存起来
- 从项目git页面中复制PATCH内容，并在本地项目根目录中新建文件，可命名为patch.diff，将PATCH内容保存到该文件中
- 在编辑器中将patch.diff里的所有$$替换为$（注1）
- 在根目录执行git apply patch.diff
- 此时可以对代码进行本次打PATCH要做的改动
- 改动完成后在本地项目执行npm run test与npm run build以确认PATCH内容无误
- 确认无误后，在本地项目根目录执行git diff > new-patch.diff，以此将本次的改动输出到new-patch.diff中
- 用编辑器打开根目录的new-patch.diff文件，将所有$替换为$$
- 将new-patch.diff覆盖项目git页面ci变量中的AG_PATCH变量的内容，点击下方的保存按钮。此时即已完成PATCH变量的修改
- 此时在ci中重新编译、部署即可将PATCH的改动上线
注1：因为shell脚本中$是关键字，所以写到PATCH中的$都需要转成$$。相应的，执行git apply patch.diff去读取PATCH之前需要将PATCH中的$$转换成$。
十二、git cherry-pick
可以选择某一个分支中的一个或几个commit(s)来进行操作，对已经存在的commit 进行再次提交。比如 存在两个分支，branch1和branch2。branch2上有几个 commit 想要转到 branch1 上，则进行操作。
// 1. 先确定 branch2 需要提交的 commit 的 id
// 2. 转到分支 branch1 上
git checkout branch1
// 3. 将 commit 提交
git cherry-pick <commit id> // commit id 是 branch2 上的
如果顺利，则正常提交；如果失败，提示冲突，则手工解决：
git status // 看哪些文件出现冲突
命令集合：
git cherry-pick <commit id> // 单独合并一个提交
git cherry-pick -x <commit id> // 同上，不同点：保留原提交者信息。
git cherry-pick <start-commit-id>..<end-commit-id> // cherry-pick一个区间的commit, ( start, end ]
git cherry-pick <start-commit-id>^..<end-commit-id> // [ start, end ]
实际应用
1. 如果git stash list有多个存储的记录，如果应用/丢弃某个特定的记录
git stash apply stash@{1} // 应用指定版本的工作 stash@{1}
git stash drop stash@{1} // 移除指定版本
2. 以git flow release finish为例，如何查看此命令有哪些后缀参数可用
命令行后面加后缀 -h
3. 接2，git flow release finish xxx，如何使用自定义tag messaage
git tag -ln // 回车备注后可以查看到
4. 在执行git add 操作之后，如何把暂存区的内容回退至工作区
git reset HEAD <fileName>
5. git rebase 完成之后，在远程仓库和本地仓库commit记录不一致的情况下，如何同步代码
强制更新(将本地的更新到远程)
git push origin <分支名> -f // 加个 -f后缀