苦队友不会 Git 久矣。为了避免每次做项目教一遍 Git，推出这篇队友必看的 Git 多人协作教程（旧文的推送，雾
学习 Git 需要多加实践，熟能生巧方为正道
队友要是连 Git 都不会，最好不要组队了
本文部分参考 Git 多人协作教程 | 异国迷宫的十字路口
写在最前#
什么是 Git 存储库 Git Repository？ 一个项目，就是一个 Git Repository。更具体一些，项目文件夹的位置，就是 Git Repository。要想一个项目文件夹成为一个 Git Repository，需要运行 git init 命令创建本地 Git 仓库（所谓本地，就是在自己的电脑上）
当然创建 Git 代码仓库也未必要本地，通过 Github 网站也可以创建 Git 代码仓库
什么是 Git？ Git 是一个版本控制系统，对 Git Repository 的文件版本进行管理。保存了你对 Git Repository 的操作记录。在需要的时候，可以从操作记录中恢复历史版本。
什么是 Github？ Github 是托管 Git Repository 的网站。用户可以将自己笔记本电脑上的 Git Repository 上传到 Github 网站，然后在台式机上下载编辑，或者与其他人进行代码同步与协作（比如大创，雾
安装 Git 程序 可以参考 Git 官网 https://git-scm.com/ ，以及各大博客网站，不再赘述。
推荐通过命令行操作 Git 但对新手来说，稍有门槛。也可以通过图形化界面操作。
Git GUI (图形用户界面 Graphical User Interface) 有很多 比如：Github Desktop, Sourcetree, GitKraken 以及各种 IDE 中自带的 Git GUI 等均可使用。
具体安装不再赘述，请通过 Bilibili 以及各大博客网站搜索。
从 clone 开始#
使用 git clone 命令从 Github 等 Git Repository 托管网站上下载我们需要的 Repository (代码仓库)。
如图所示，就是我们所需的链接地址了。我们只需使用 git clone 命令，再加上我们复制得到的地址，就可以拉取我们想要的仓库了。
git clone https://github.com/github/site-policy.git
此处代码将拉取 github 官方的 site-policy 仓库
如果使用命令行的方法克隆仓库，需要注意，仓库会被下载到命令行当前路径下。修改路径可用 cd 命令。具体可查阅各大博客平台。
如果有余力，可以为 Github 配置 SSH Key，这样就可以使用 SSH 协议 clone 代码仓库了 同样，此处不再赘述。
当我们完成了代码仓库的 clone，意味着我们在自己的电脑上也有了一份和 Github 上一模一样的 Git Repository。
我们将自己电脑上的代码仓库称为 local repository，在 Github 或者其他托管网站上的代码仓库称为 remote repository
❗❗打开电脑本地的 repository，或许你会发现一个名为 .git 隐藏文件夹，需要特别注意的是，这个 .git 文件夹保存了 repository 所有的修改记录以及远程连接信息
❗❗如果将 .git 文件夹删除，那么当前项目就不再是一个 repository，而与普通文件夹没有任何区别了。
Git 代码更改与上传#
前面我们说过，可以认为项目文件夹就是 Git Repository
对于代码文件，不可避免地，我们会删除一些错误，添加一些功能，这就涉及到文件的新建、删除、修改。
按了 Ctrl+S，代码仓库就更新了吗？ 并不是这样。
Ctrl+S 快捷键可以保存文件，但不能更新 Git 的记录。也就是说，在我们的视角下，代码确实是修改了，但在 Git 的视角下，代码并没有发生改动。
关于文件新建与文件删除，也是类似的情况。
那么，如何让 Git 也能察觉到文件的变动呢？
需要使用 git add 命令。
git add *
此处 * 是通配符，表示作用于所有文件。
其他用法可以参看 git add 命令 | 菜鸟教程 或各大博客网站的相关博文。
虽然 Git 察觉到了你对文件的修改（文件进入了暂存区），但并没有生成操作记录（修改没有进入本地仓库）。
既然这样，如何更新 Git 仓库呢？
需要使用 git commit 命令将修改提交到本地仓库。此时，才会在 git log 中生成 “操作记录”。
git commit -m "my first commit"
此处 -m 为 commit 操作传入一个参数，作为本次提交的 message 通常这个 message 是对本次提交的一个概括。
commit message 模板
参考 conventional commits 或 Commit message 和 Change log 编写指南 - 阮一峰的网络日志 力求简单明了。
git commit 命令的其他用法可以参看 git commit 命令 | 菜鸟教程 和其他教程资料。
至此，我们成功更新了 local repository 也就是自己电脑上的代码仓库
但随之而来的是一个问题 —— 我们修改了 local repository 本地仓库，但 Github 网站上的 remote repository 远程仓库，并没有人动过，这时候，两个仓库出现了不一致。
我们把更新的版本（我们修改过的 local repository）上传到 github 上，去更新 remote repository
这个过程使用 git push 命令
git push origin main
执行上述代码后，本地的 main 分支会上传并覆盖远程的 main 分支。
参考 git push 命令 | 菜鸟教程 查看更多语法细节。也可以查阅其他教程网站。
Git 代码同步与下载#
当 github 上远程代码仓库比自己电脑本机上本地代码仓库新的时候，我们需要下载代码。
这时，可以使用 git pull 命令
git pull origin main
这时候，远程代码仓库的 main 分支就会被拉下来，然后更新本地的 main 分支。
更多信息，可以参考 git pull 命令 | 菜鸟教程 和其他资料。
代码冲突与解决 如图是取自网络的一个代码冲突案例
<<<<<<<<<<<
A
===========
B
>>>>>>>>>>>
这个记号叫做冲突记号 如上，A 和 B 是互相冲突的。
一般 IDE 会自动识别冲突记号，然后将对应的冲突代码高亮（图中显示为绿色和蓝色）并给出冲突解决的快捷菜单：包括 Accept Current Change, Accept Incoming Change, Accept Both Change 和 Compare Changes。单击对应的选项，就可以实现两段代码二选一。
有时候，冲突记号不能被正确识别，就需要手动删除重复代码和冲突记号，否则合并会出错。
实际上，在代码 push 的时候也有可能出现这样的状况。解决方法类似。
分支管理#
使用 git branch 命令和 git checkout 命令创建分支、切换分支。命令的使用不再赘述，参考 git branch 命令 | 菜鸟教程 以及其他相关资料。
Git 分支的命名和功能：
- master/main（主分支，永远是可用的稳定版本，不能直接在该分支上开发）
- develop（开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做合并操作，不能直接在该分支上进行开发）
- feature-xxx（功能开发分支，在 develop 上创建分支，以自己开发功能模块命名，功能测试正常后合并到 develop 分支）
- feature-xxx-fix（功能 bug 修复分支，feature 分支合并之后发现 bug，在 develop 上创建分支进行修复，之后合并回 develop 分支）
- hotfix-xxx（紧急 bug 修改分支，在 master 分支上创建，修复完成后合并到 master）
- bugfix/* 分支 （短期从 develop 创建）
- release/* 分支（短期从 develop 创建）
各分支的关系，可以参考下图。
如上所述多人协作开发的项目，常以多分支并行的方式推进。不允许直接 push 到 main/master 分支和 develop 分支上。
为什么不能直接 push 到 main/master 分支？ 因为 main/master 分支应当是一个稳定的分支。没有恶性 bug，几乎随时可以使用，基本实现预定功能。
当然，许多朋友可能也曾经使用过 git 管理个人小型项目，这时候当然没有那么多讲究。
使用 Pull Request (PR) 合并代码 PR 的方法可以避免直接 push 造成不可预期的结果，能够支持代码审查，还可以引入自动化工具辅助等等。
具体可以参考 为什么不能直接 push 到 master 分支 | Weitang Li's blog
如何发起 PR 参考下图，根据页面提示操作即可。
必读的开发流程#
几个重要的点，必须强调一下
开发前务必执行 pull 操作#
每一次开发前都要 pull❗解决可能存在的冲突，并更新代码。也避免重复工作
不使用 main (master) 分支和 develop (dev) 分支开发#
我们禁止直接 push 到 main 分支和 develop 分支上。新建对应的 feature (feat) 功能分支开发是最优解。
分支 feature-xxx 的命名可以根据要开发的功能而定。然后使用 PR 来合并代码。
PR 的方向： 从 feat 等分支提交到 dev 分支，然后由 dev 分支提交到 main 分支，不要越级提交
若违反此步骤，造成分支混乱，后果绝对是地狱级别难度
代码提交以及 PR 写清楚 commit message#
告诉队友你干了什么❗节省大家的时间。具体可见上文。
分支合并需要 rewiew#
通常 PR 不会直接通过，可能需要同组其他成员进行代码复查，然后才能被允许合并。关注 PR 界面的评论区，可以及时收到反馈和修改建议。
不确定就不要操作，在群里问#
比如产生了代码冲突，有时候并不是别人的代码不对；
又比如可能产生了没有见过的问题等等……
搜索解决方案是一方面，一定要和其他队员说一声，不要闭门造车😅
Good Luck#
祝好