配置git的ssh key，
首先用如下命令（如未特别说明，所有命令均默认在Git Bash工具下执行）检查一下用户名和邮箱是否配置（github支持我们用用户名或邮箱登录）：
git config --global --list 笔者的机器显示信息如下（已配置）：
如未配置，则执行以下命令进行配置：
git config --global user.name "这里换上你的用户名" git config --global user.email "这里换上你的邮箱" 然后执行以下命令生成秘钥：
ssh-keygen -t rsa -C "这里换上你的邮箱"
简易工作流把远程仓库clone到本地git clone 远程仓库路径 从master上切出来一个新的分支，在其上面做开发git checkout -b 分支名 把开发完成的功能做提交git add . git commit -m 'sssss'
# 反复执行提交操作 切回master分支，从服务器获取master分支最新的内容git switch master 合并刚才的临时开发分支到master之上git merge 临时的开发分支 把合并之后的master分支推送到服务器git push git remote -v 查询远程仓库
git remote add xxx
git push master:master 将本地master推送到远程master
在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：
$ git remote add origin git@github.com:michaelliao/learngit.git
请千万注意，把上面的michaelliao替换成你自己的GitHub账户名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：
$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。
Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
这个警告只会出现一次，后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
git 为什么好，为什么要用 git，这不是我本文想要说明的问题。
这里想要给大家分享一下自己使用过程中产生的疑惑，以及解决的这些疑惑的过程。话又说回来，我现在依然充满疑惑。真不知道30岁的时候会不会不惑。
在使用 git 过程中，它的分支功能让我真的欣喜若狂，不过这是把双刃剑，一不小心你会得到这种git路径图：
我的疑惑： 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 分支。
什么时候要预发分支？
这个分支是为预发准备的，测试的介入，也只应该在该分支产生时才介入。当我们不管是新功能开发，还是一般的bug修改都差不多了。就应该从develop产生一个release分支，交给测试，如果有bug直接在上面修改。全部完成后，合并回develop，并且合并到master。
关于这个分支我得再多说几句。因为这是非常重要的一步，如果我们使用了 git 钩子，当合并到 master 的时候，会自动发布到线上，所以这是临上线的最后一道屏障。
同时这里也解决了我一个疑惑，测试如何参与到git的每个分支中来？答案是：测试不应该参与到每个分支中来，只应该参与到release分支中去。其它的开发分支，都应该由开发人员自己测试，测试没有问题的时候才准许合并到develop，这就要求每一个开发要提高自己交付的产品质量，如何确保自己交付的产品质量？自动化测试是个不错的选择，好了，打住，这不是咋们今天的主要任务，这个话题改天再聊。
什么时候需要补丁分支？
这种情况越少越好。因为它产生的原因是：线上出了bug，并且必须马上修复，不管你身在何方，当手机响起，拿出电脑改bug吧。
它与release 很像，都需要完成后，同时合并到:master与develop。不同的是，它需要从master 上开一个分支出来。 转存失败重新上传取消
注意这里没有测试的介入，一半来说都是代码上某一个小的紧急bug，虽然很严重，但是可以很容易改动。当然如果有一些例外情况，应该让测试进行测试后再合并、发布。
总结git 开发很好用，但是要按照一定规则合理使用分支。
另外，除了:master与develop 分支，其它分支都不应该出现在远程仓库中。
用git一定要结合它的各种钩子来使用，提升开发效率。这里后面来介绍下。
参考资料:
常用 Git 命令清单 - 阮一峰的网络日志
- [1]Git 工作流程
- [2]介绍一个成功的 Git 分支模型
