Git相关教程

廖雪峰的Git教程 
git - 简明指南

git使用笔记

1. Github的使用

Github是一个免费的远程仓库，一个开源协作社区

1.1 如何参与Github上一个开源项目

  1. 访问它的项目主页，点“Fork”就在自己的账号下克隆一个仓库

  2. 从自己的账号下clone： 
    git clone xxx 
    一定要从自己的账号下clone仓库，这样你才能有权限推送修改。

  3. 如果想修复bug，或者新增功能，改完后往自己的仓库推送，如果希望项目的官方库能接受你的修改，就可以在Github上发起一个pull request。当然对方是否接受就不一定了。

小结

  • 在GitHub上，可以任意Fork开源仓库；

  • 自己拥有Fork后的仓库的读写权限；

  • 可以推送pull request给官方仓库来贡献代码。

2. 创建新仓库

创建新文件夹，打开，然后执行

git init

3. 检出远程库

  1. 创建一个本地仓库的克隆版本 
    git clone /path/to/repository

  2. 如果是远端服务器上的仓库，你的命令会是这个样子： 
    git clone username@host:/path/to/repository

    这里的地址支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。 
    使用https除了速度慢，每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

  3. 如果没有克隆现有仓库，而是想将你的仓库连接到某个远程服务器，试用一下命令： 
    git remote add origin <server>
  4. 不想每次都输入密码

Generating a new SSH key

Adding a new SSH key to your GitHub account 
密码 :root123

======================================================================================================

开发生涯的前三年都是使用 svn，回首放佛如前世。自从用了 git ，整个人都神经了。

下面的内容肯定不是什么教你如何用git提交代码，合并分支之类的。现在本人要从写术的层面提升一下自己文章的品质到道的层面。

使用git带来的分支疑惑

git 为什么好，为什么要用 git，这不是我本文想要说明的问题。

这里想要给大家分享一下自己使用过程中产生的疑惑，以及解决的这些疑惑的过程。话又说回来，我现在依然充满疑惑。真不知道30岁的时候会不会不惑。

在使用 git 过程中，它的分支功能让我真的欣喜若狂，不过这是把双刃剑，一不小心你会得到这种git路径图：

image

图片来源：阮一峰老师博客

我的疑惑：

  1. 那么团队中我们该使用怎样的分支策略来进行开发协作？
  2. 在多人的团队中，我们应该在 master 分支上直接开发吗？
  3. 如果线上产生了bug该通过什么样方式的分支去修复？
  4. 当有多个分支的时候，测试如何有效的参与进来每一个分支的测试？

用成熟的工作流来解决问题

在解答上面的疑惑前，先介绍几个工作流，然后通过工作流的模式，来进行解答。因为我们必须在某种设定的情景下，才能讨论解决问题的思路。

下面三种工作流方式，都是采用功能驱动开发，也就是先有需求产生，然后诞生对应的分支，然后开发，最后合并回来，完成使命被删除。

  • Git flow
  • Github flow
  • Gitlab flow

关于这三种工作流的详细介绍，建议看看这篇文章-阮一峰

我现在采用的是 Git flow ，经过自己的实践，确实好用，解决不少问题。然后如果发现与自己的实际情况有些出入，可以根据需求做出些变动调整。

我的选择

我选择了 Git flow，它的主要特点是，长期存在两个分支：

  • 主分支master
  • 开发分支develop

然后，存在三种辅助分支，都是短期的，并且一半情况下只应该存在本地，不要提交到远程库。

  • 功能分支（feature branch）
  • 补丁分支（hotfix branch）
  • 预发分支（release branch）
    在进行上面的分支时，建议的命名规范：feature-xxx、release-xxx、hotfix-xxx

话外：我以前喜欢用下划线，后来发现打中线不需要按 shift ，哈哈，从此开始中线时代。

什么时候要功能分支？

当你拿到一个需求，或者不是一个立马需求上线的bug修复，那么就应该从 develop 开一个分支出来，完成这部分工作。完成后合并到 develop 分支。

image

什么时候要预发分支？

这个分支是为预发准备的，测试的介入，也只应该在该分支产生时才介入。当我们不管是新功能开发，还是一般的bug修改都差不多了。就应该从develop产生一个release分支，交给测试，如果有bug直接在上面修改。全部完成后，合并回develop，并且合并到master。

关于这个分支我得再多说几句。因为这是非常重要的一步，如果我们使用了 git 钩子，当合并到 master 的时候，会自动发布到线上，所以这是临上线的最后一道屏障。

同时这里也解决了我一个疑惑，测试如何参与到git的每个分支中来？答案是：测试不应该参与到每个分支中来，只应该参与到release分支中去。其它的开发分支，都应该由开发人员自己测试，测试没有问题的时候才准许合并到develop，这就要求每一个开发要提高自己交付的产品质量，如何确保自己交付的产品质量？自动化测试是个不错的选择，好了，打住，这不是咋们今天的主要任务，这个话题改天再聊。

什么时候需要补丁分支？

这种情况越少越好。因为它产生的原因是：线上出了bug，并且必须马上修复，不管你身在何方，当手机响起，拿出电脑改bug吧。

它与release 很像，都需要完成后，同时合并到:master与develop。不同的是，它需要从master 上开一个分支出来。
image

注意这里没有测试的介入，一半来说都是代码上某一个小的紧急bug，虽然很严重，但是可以很容易改动。当然如果有一些例外情况，应该让测试进行测试后再合并、发布。

总结

git 开发很好用，但是要按照一定规则合理使用分支。

另外，除了:master与develop 分支，其它分支都不应该出现在远程仓库中。

用git一定要结合它的各种钩子来使用，提升开发效率。这里后面来介绍下。

参考资料:

介绍

我是何磊，主要工作就是写代码，持续创业者（之所以持续是因为到现在还没有干成功过一件事）。如果你有兴趣欢迎关注我，我会分享技术，还有生活，当然还有我创业的故事（说出我的痛，让你开心一下）。

因为自己的博客没有留言功能，同时也需要大家记住域名很麻烦，因此我开通了这个公众号，希望在这里遇见你：

image