极简Git使用说明 - Chuckiefan's Blog

本文档的目的是为了在零基础的情况下，通过Git一些基本的操作命令和一些规约的说明，尽快上手Git的基本使用，更多内容请参考Git的官方文档。

此外如果想完整学习Git，请从设计思想和原理入手¹。

Git配置

在Git安装完成以后，请打开Git Bash进行基本的配置。在Windows下，任意位置右键，并点击”Git bash here”；在*nix下，打开终端：

git config --global user.name "姓名"
git config --global user.email "邮箱地址"

注1： --global参数用于指定全局配置；如果仅针对当前项目，那么在当前项目下输入命令时，将--global改为--local，此外--local也是默认参数，可不添加。

注2：上述配置并不会有任何机制对配置内容的有效性进行验证，它只是表明了文件、commit的提交、修改由谁来完成。可通过git blame以及git log等命令查看到相关信息。有效性验证则通过结合GPG签名完成，此处不进行更多讨论。

可使用HTTP以及SSH的方式从远端仓库拉取代码，推荐使用SSH的方式。由于目前我们的Gitlab通过SSH连接暂时存在问题，先通过HTTP的方式使用。

在这里进行SSH和HTTP切换：

HTTP连接时，每次和远端仓库的交互都需要输入账号和密码，为了便捷使用，请先在Git的全局配置中进行如下修改：

git config --global credential.helper store

此时，输入的账号密码可被Git保存在磁盘中，每个Git仓库只需要输入一次便不需要再次输入。

通过git config --list可查看当前配置，如果配置成功，可以在命令的输出结果看到如下一行：

credential.helper=store

从远端拉取代码，可输入如下命令：

git clone <url>

Git Flow是一套Git的使用流程，从需求开发到版本发布到紧急修复进行了使用规则上的约束²，此处根据开发流程进行基本的介绍。

每次进行新需求开发时，请切换到develop分支，并以develop分支为源分支，创建本地需求分支：

git checkout develop
git checkout -b 需求分支名

git checkout -b是两个命令的组合，即创建分支和切换分支，相当于：

git branch -r 新分支名 # 创建本地新分支
git checkout 新分支名 # 切换到刚创建的新分支

此时可进行开发，在开发完成以后，将已修改、新创建、已删除的文件进行git add操作，并提交：

git add 文件名 # 已修改、新创建、已删除的文件都要进行该操作
git commit -m "提交说明"

在本地需求分支中，可根据需要进行一次或若干次的代码提交，并不受限制。

在开发完成以后，切换回develop分支，先拉取远端服务器的代码。

git checkout develop # 切换回develop分支 
git pull --rebase # 拉取远端服务器的代码，请务必记得添加--rebase参数

之所以需要先拉取远端代码，是因为在多人协作开发下，当你在开发时，其他人可能已经提交并推送代码。在开发完成以后先对develop更新，使其和远端保持同步，然后再合并本地分支。如果颠倒这两件事的顺序，就会在合并代码时遇到很多不必要的麻烦，一旦出现冲突需要回退时，处理也比较繁琐。

在拉取远端代码以后，将本地需求分支合并至develop分支，并推送：

git merge 创建的新分支名 --no-ff --no-edit # 合并本地创建的需求分支
git push # 推送到远端服务器

注：–no-ff参数是强制使用非fast forward模式，–no-edit参数指定自动创建的commit不需要人工添加注释，由Git完成commit的注释工作。另，在合并的过程可能会遇到需要人工解决的冲突问题³。关于Git合并的详细细节，请点击这里。

根据Git Flow的规范，在完成上述操作以后删除本地创建的需求分支：

git branch -d 创建的新分支名 # 删除分支，注意-d的字母为小写，不要使用-D参数，该参数为强制删除

至此，一次开发流程结束。

最后整理并介绍一些在实际使用Git时应当遵守或者参考的规则：

在提交，切换分支，拉取代码之前，请务必记得通过git status查看当前工作目录(working directory)是否是干净(clean)的。
多提交，少推送。多人协作时，推送会频繁地带来合并冲突的问题，影响效率。因此，尽量多使用提交命令，减少合并的使用，这样会节省很多时间。
使用分支，保持主分支的整洁。这是我强烈推荐的一点，在分支进行提交，然后切到主分支更新(git pull —rebase)，再合并分支、推送。这样的流程会避免交叉合并的情况出现（不会出现共同祖先节点为多个的情况）。事实上，git合并操作让很多人感到不知所措的原因就是各种原因所产生的交叉合并问题，从而造成在合并的过程中丢失某些代码。保持主分支的整洁能够避免交叉合并的情况出现。
禁用fast-forward模式。在拉取代码的时候使用rebase参数（前提是保持主分支的整洁）、合并的时候使用—no-ff参数禁用fast-forward模式，这样做既能保证节点的清晰，又避免了交叉合并的情况出现。
在分支间的合并时，一定要遵守单向合并规则，即避免criss-cross merge（交叉合并）的情况出现，交叉合并可能会导致代码丢失的问题。