学习总结
- 学习datawhale的git教程。标准式的提交与合并：运用Pull Requests（优点：更严谨&利于把控每个版本的质量。例如Forking 工作流）。
- 使用的是Forking 工作流，也就是先把仓库Fork到个人账号，（为了避免误操作影响主分支，往往还需设置禁用向主仓库直接push，也就是禁用前一节所述的粗放式提交），然后再用PR请求的方式将fork的修改提交给仓库管理员审核，审核通过之后再合并入主分支；可以参考atlassian文档。
- 这类比较正式的工作流也往往需要更加严谨的提交信息格式。
- 提交信息使用如下格式：
<type>: <short summary>
<type>: <short summary>
│ │
│ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│
└─⫸ Commit Type: lecture{#NO}|others
-
others包括非项目主体内容相关的改动，如本README.md中的变动，.gitignore的调整等。 - 代码比较工具Beyond Compare：将bc用作代码比较工具可以较为方便地在git中进行配置，且拥有较成熟的图形化界面（对 不同系统的换行符CR、lF，也能较为合理地自动处理），相比与手动解决冲突的效率还是会好许多。
文章目录
- 学习总结
- 九、Git 图形工具
- 9.1 GitHub Desktop
- （1）登录
- （2） 建立首个仓库
- （3）提交Pull Request
- 1）fork
- 2）commit & push
- 3）PR
- 9.2 TortoiseGit
- 9.3 Vscode Git
- 十、Git团队协作，合并时的diff工具
- 10.1 代码提交到远程仓库
- （1）粗放式的提交：
- （2）标准式的提交与合并：
- 10.2 代码比较与冲突处理
- （1）配置bc（Beyond Compare）
- 直接用git命令配置
- （或者修改配置文件）
- （2）使用bc
- 情形1：在merge中使用
- 情形2：作为替换diff命的图形化界面
- Reference
九、Git 图形工具
开源分布式版控制系统git能方便处理项目版本管理，但在实际研发中，工程师可能只会使用几个常见的命令进行协同工作，git GUI图形化工具提供图形化界面。
9.1 GitHub Desktop
- GitHub Desktop 正是 Github 推出的开源 Git GUI 图形客户端。
- 可以在Windows和Macos平台上进行使用，目前暂不支持Linux平台。
（1）登录
完成下载后，第一次打开软件会直接要求登录个人 Github 账户进行授权，并配置用户名和邮箱（识别个人创建的commits提交）。
登录：File -> Options -> Accounts -> Sign in 登录。
在完成基本配置后，会出现如下界面：
（2） 建立首个仓库
初次登陆会看到三个选项，也就是建立自己的第一个repository。
建立一个repo可以通过三个方式：
- clone a repository：克隆一个repo
- create new repository：建立一个新的repo
- add a local repository：添加一个本地的repo
我们先选择从URL中克隆 faster-git 仓库，如下图，需要修改的地方为URL链接以及本地存储的路径。
（3）提交Pull Request
1）fork
由于在实际开源项目贡献的过程中，开发者往往并没有直接修改仓库内容的权限，因此需要先对目标仓库进行fork操作，再通过提交PR的方式进行代码的贡献。在下图中，可以通过左下角的warning标志⚠，判断用户是否有目标仓库的权限。如果没有写入权限，点击create a fork，将目标仓库复刻为自己的仓库，进行随意的修改。
在 Github Desktop 中完成fork后，登录 Github 网页就可以在个人仓库中看到目标仓库的复刻版，如下所示。
2）commit & push
在完成了fork后，当前仓库就会索引到用户个人的复刻仓库，对应于本地指定目录下的文件。此时，用户拥有复刻仓库的所有权限，包括修改，删除，更改可视状态等等。接下来，就可以对本地分支中的代码进行修改，更新而当操作，再push到用户个人的复刻仓库中。
此时，登录 Github 网页版就会发现本地修改的代码已经上传到云端，个人复刻仓库进行了本地同步。
3）PR
在完成个人仓库的代码更新后，还要注意个人仓库的分支和目标分支的先后情况，如果目标分支领先于fork分支，需要先通过fetch upstream操作进行更新后，再提交PR。
upstream分支指向上游地址即目标分支，这里的upstream名字可以任意指定，只是一般都把上游地址都叫upstream。
点击Contribute，并Open pull request，向目标仓库提交上传申请。
在完成PR后，会自动跳转到目标仓库，可以看到在Pull requests一栏中，上标增加了1，1就是贡献者所提交PR。之后就需要目标仓库的拥有者对贡献的代码进行审阅，如果代码合规可利用，就会将fork分支的commits合并到主分支中。这样一来，就完成了一次贡献！！👏👏
9.2 TortoiseGit
- TortoiseGit 简称 tgit， 中文名海龟 Git ，是一个开放的 Windows 系统下的 Git 版本控制系统的源客户端，提供有中文版支持。
- 它不是针对特定IDE(如Visual Studio、Eclipse或其他)的集成，所以可以与任何开发工具和任何类型的文件一起使用。
- 与 Github Desktop 一类的传统图形化交互不同，TortoiseGit 的交互主要利用 Windows 资源管理器的上下文菜单，因此不需要打开任何软件，十分轻量、便捷。
9.3 Vscode Git
在实际项目开发过程中，往往遇到的场景是项目开发者直接通过代码编辑器进行Git操作，如在Vscode中进行Git基本操作。
导入项目文件，选择侧边栏的第三项，就可以看到以下内容。
首选暂存所有更改，再在消息栏中输入message并点击勾进行提交，或者使用快捷键Ctrl+Enter进行提交。
完成add和commit操作后，点击同步，即可以push到远端。
十、Git团队协作，合并时的diff工具
在许多的多人组队（编程）任务、尤其是需要进行交叉修改代码中部分段落的时候，Git这样一个分布式版本控制系统的优势就体现出来，或许这也是一些人开始接触和使用Git的原因。
"在实际项目开发工作中，常常会有自测、联调、提测、线上紧急修复等多工作环节，对应可能需要本地、内测、开发、测试、生产等多环境部署代码的需求，对应每个环节会产生不同的分支。
10.1 代码提交到远程仓库
（1）粗放式的提交：
粗放式的提交：加入仓库协作者，即可获得直接push的权限（优点：更方便&快捷）以Github为例，首先，仓库管理员（一般是仓库的创建者或者拥有者）先在Github上仓库的Settings页面中点击下图的Add People按钮，添加合作者：
约定大致的Commit Message（提交信息）的格式，有fix，update，merge等词语放在提交消息的开头，来大致表示这次提交的大致内容。
（2）标准式的提交与合并：
标准式的提交与合并：运用Pull Requests（优点：更严谨&利于把控每个版本的质量。例如Forking 工作流）。
使用的是Forking 工作流，也就是先把仓库Fork到个人账号，（为了避免误操作影响主分支，往往还需设置禁用向主仓库直接push，也就是禁用前一节所述的粗放式提交），然后再用PR请求的方式将fork的修改提交给仓库管理员审核，审核通过之后再合并入主分支；可以参考atlassian文档。
此外，这类比较正式的工作流也往往需要更加严谨的提交信息格式，例如本项目提交信息采用如下格式：
提交信息使用如下格式：<type>: <short summary>
<type>: <short summary>
│ │
│ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│
└─⫸ Commit Type: lecture{#NO}|others
others包括非项目主体内容相关的改动，如本README.md中的变动，.gitignore的调整等。
实际上一些更大型的项目或者企业，可能会涉及到统筹配置多个仓库及其参与者的权限，因此会用到Projects以及Organization等功能。
10.2 代码比较与冲突处理
- 与团队协作相伴的往往就是修改冲突（Conflit）的问题了，第三章中已经提到了一些处理冲突的一般方法（例如手动修改和暂时终止Merge进行排查）
- 用于进行代码比较的软件——Beyond Compare（或者简称bc，其官网为https://www.scootersoftware.com/download.php ，下文中所使用的版本为4.4，其他版本可能略有差异，比如对一些路径中含有的版本号数字可能需要微调，但主要功能基本一致）。
将bc用作代码比较工具可以较为方便地在git中进行配置，且拥有较成熟的图形化界面（对 不同系统的换行符CR、lF，也能较为合理地自动处理），相比与手动解决冲突的效率还是会好许多。
（1）配置bc（Beyond Compare）
在bc完成安装之后：
直接用git命令配置
其中C:/Program Files (x86)/Beyond Compare 4为（32位版本的）bc4的默认安装位置，如果安装时自定义了位置，需要相应地修改。（此外，因代码中有若干个带\ 的转义字符，请注意不要因手滑而删除之。）
（这里是直接做了git的全局配置，如果只想让它在某个代码仓库生效可以将下面这段中的global都改为local。）
$ git config --global diff.tool bc4
$ git config --global difftool.bc4.cmd "\"C:/Program Files (x86)/Beyond Compare 4/BComp.exe\" \"\$LOCAL\" \"\$REMOTE\" \"\$BASE\" \"\$MERGED\""
$ git config --global difftool.bc4.trustExitCode true
$ git config --global merge.tool bc4
$ git config --global mergetool.bc4.cmd "\"C:/Program Files (x86)/Beyond Compare 4/BComp.exe\" \"\$LOCAL\" \"\$REMOTE\" \"\$BASE\" \"\$MERGED\""
$ git config --global mergetool.bc4.trustExitCode true
如果输入命令后均无报错，则可跳过下面带括号的这个小节。
（或者修改配置文件）
打开global（全局）或者local（某个项目）的配置文件，全局配置文件一般在用户文件夹下，可用如下命令打开
$ cd ~
$ vim
而local的配置文件则是在本地代码仓库文件夹的.git目录下的config文件。当然，在local中修改就不会在其他代码仓库文件夹里共用这个配置了。
在文件尾部新建一行，追加如下配置代码 并保存：
[diff]
tool = bc4
[difftool "bc4"]
cmd = \"C:/Program Files (x86)/Beyond Compare 4/BComp.exe\" \"$LOCAL\" \"$REMOTE\"
[merge]
tool = bc4
[mergetool "bc4"]
cmd = \"C:/Program Files (x86)/Beyond Compare 4/BComp.exe\" \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
trustExitCode = true
（2）使用bc
情形1：在merge中使用
也就是在第三章所提到的“融合到主分支上时就会发生冲突。如下图所示：”（此时分支名右侧往往还会出现MERGING的高亮提示。）
此时直接用命令：
$ git mergetool
即可直接bc的界面：
bc较好的功能之一正是在于将"<<<<<<“,”=======“,”>>>>>>"等分割线转换为更直观的三个完整的小窗口显示，并用色块来标记并可以直接点击选择保留哪些部分，可以直接点击Next Section以及 Prev Section在各个差异区段间切换，中间小窗口（文件名中一般会加入BASE）的是差异版本的最近共同祖先，左右分别是冲突的两个版本，修改合并后的完成效果显示在屏幕下半区的大窗口中。最终对比和修改完成并保存后可直接关闭窗口，如有大于一个有差异的文件，bc会自动打开后续需对比的文件。
保存完成，继续到git bash进行commit以及push就可以愉快地完工啦！！
情形2：作为替换diff命的图形化界面
在一般情况下可以直接将diff命令直接替换为difftool命令，即可在bc的界面看到diff状态的内容，如下图：
仍可以类似地点击Next Section以及 Prev Section在各个差异区段间切换，并进行其他修改操作。
Reference
- datawhale notebook
- Git Book
- 廖雪峰Git教程
- Git权威指南
- freenode
- Github-cheat-sheet
- 动手学Git
- learn git branching
- Git 官网
