Git客户端使用教程

课程地址《版本控制入门 – 搬进 Github》

笔记参考《搬进 Github》

Git客户端的使用

Git for windows下载

新建一个仓库tata，使用sublime新建一个文件hello，如图

回到GitHub客户端，如下所示，显示了文件的变化，如果只需要先提交hello，可单击good所在的行忽略good

在左下角填写对本次提交的描述：

点击History可查看历史提交

如果要撤回提交，则在changes中选择undo即可。但是undo操作只适用于还没有同步的版本，即还没有同步到Github网站上。可通过如下操作进行撤回

没有找到版本回滚，好像是取消了，还是通过命令行进行了版本回退操作。原来觉得命令行有些麻烦，有点怕使用，但其实想想应该多用命令行，掌握基本的操作其实也不难。

将本地仓库同步到Github网站上，点击

私有为付费项目，取消选中，填写描述，过一会可在自己的Github网站上看到同步成功的仓库

简单分支操作

创建新分支

如下创建一个新分支idea

如下，分支idea创建成功，打钩表明当前指针指向idea分支

默认情况下这个 idea 分支只是存在于本地，如果想在远端仓库上发布这个分支，就点一下 idea 分支右侧的 Publish 按钮。

这样，到远端仓库看一下，发现多了一个 idea 分支，输入框中不但能搜索已有分支，还能创建新分支。很多操作在本地客户端和 github.com 上都能进行。

删除分支

合并分支

切换到要合并到的分支，例为master，选择Branch中的Merge into current branch

选择要合并到mater的分支，点击merge into master即完成合并操作。merge 之后， master 分支指针指向了 merge commit，也就自动拥有了 idea 分支上的最新版本了。idea 分支一般这会儿就可以删除了。

master 中拥有了 idea 中的所有代码。底层历史新生成了一个 C5 ，这是一个“融合版本”（ Merge Commit ）这个合并挺特殊，里面一般没有修改内容，它的作用主要是把两个分支合并起来。怎么合并的呢？把 master 的内容 sync 到 github.com 上，然后查看一下这个 merge commit ，会发现它有两个 parent

代码冲突 conflicts

实际中经常有这样的情况，我正在 idea 分支上开发一个比较大的功能。但是这个时候突然发现了一个紧急的问题需要修复，所以我会直接到 master 分支上，做一个 commit 来解决这个紧急的问题。然后会来继续到 idea 上开发。

其他的情形也有，总之这样就会出现，两个不同分支上并行开发，同时都有新的 commit ，这个一般没有问题，一样可以直接 merge

但是如果在两个分支上改动了同一个地方，合并的就会出现代码冲突。因为 git 不知道该听哪个分支的，所以只能报出冲突的位置，让开发者手动解决。

来具体操作一下。在 idea 分支上，改动 hello文件中的一行，比如改成 AAA，commit 了，然后切换到 master 分支上，把这一行的内容改为 BBB ，也一样做 commit。这样再到客户端，把 idea 分支 merge 到 master 之中，操作不会直接成功，而是会看到下面的代码冲突界面。

右击打开存在冲突的文件，看到如下内容

<<<<<<< HEAD
BBB
=======
AAA
>>>>>>> idea

注意上面的 HEAD 是代表当前分支，此刻对应我的情形就是 master 。所以 ===== 就是两个冲突代码块的分界线了。上面的代码就是 master 分支上的，下面的代码是 idea 分支的。解决冲突就是把上面的三行“冲突标示符”都删掉，然后修改代码。之后，回到客户端，点击 2 处的 Commit to Master 。这样，这次分支合并就完成了，也会生成一个 merge commit 。

合并分支除了融合（ merge ）还有另外一种形式叫”变基“（ rebase ）这里暂时用不上，先不管。

团队合作流程

Github 多年来总结出来一套自己的团队协作流程，简单而且强大，叫做 Github Flow ，网站上的各个功能都是围绕着这个流程来开发的。另，中文版的 Github Flow 在这里。

要了解一个流程，没有什么比跑一个最简单的实际例子更好的方式了，官方给出的Hello World就是服务于这个目的，不过这个 Hello World 用的是纯粹的网页来实现整个流程。

给队友添加写权限

Settings->collaborator　　

开分支并在上面开发

发 Pull Request

PR 在整个 Github Flow 流程中占有核心位置。其实 PR 的目的就是讨论，且整个讨论过程是围绕着实打实的代码。

先到仓库页面，找到发 PR 的大绿按钮

下面图中显示的界面中，看1处，注意一下是拿出哪两个分支来进行对比。2处，我要填写一些内容，解释一下我的修改内容。3处，可以上传图片。同样在这个页面上，滑动到下方还可以看到这次 PR 的具体对比出来的代码内容

点击 Create Pull Request 按钮，这样发 PR 就成功了。

补充一句。实际上，客户端中也可以发 PR，达成的效果跟网页中发是一样的，这里就不演示了。

讨论审核代码

如果代码需要调整，那我现在是不是要撤销这 PR 重新发呢？不用。我只需要继续在分支上改代码然后再同步上来。

快速 PR

走一遍 Github Flow 其实方式并不唯一。前面讨论的，在自己的机器上改代码，用客户端作 commit，然后在网页上发 PR 是一种常见的方式。如果我只是改一个文件中的一个小地方，完全可以使用 github 网页功能提供的快速 PR这种方法。来演示一下。

网页界面中，找到我要修改的文件，点击编辑

在下面的界面中，可以直接填写一个 Topic 分支名，创建这个分支，并 commit 到这个分支上即可发 PR 了

Github issues

Github 上的每个项目仓库，都有三套基础设置可供使用：一个是通过 Github Pages 机制建立项目网站。另外一个就是每个项目都可以开自己的 wiki ，作为项目的知识库。第三个是事务卡片（ Issues ）。很多比较复杂的项目管理软件会把“报 Bug ”，“提新需求”，“其他讨论”，这些项目相关的内容分成不同的板块来进行，在 Github 这里，所有的内容就都作为事务卡片来统一管理了。