Git&GitHub

　　Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。  Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。

从一般开发者的角度来看，git有以下功能：

• 1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。

• 2、在自己的机器上根据不同的开发目的，创建分支，修改代码。

• 3、在单机上自己创建的分支上提交代码。

• 4、在单机上合并分支。

• 5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。

• 6、生成补丁（patch），把补丁发送给主开发者。

• 7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。

• 8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：

• 1、查看邮件或者通过其它方式查看一般开发者的提交状态。

• 2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。

• 3、向公共服务器提交结果，然后通知所有开发人员。

优点：

• 适合分布式开发，强调个体。

• 公共服务器压力和数据量都不会太大。

• 速度快、灵活。

• 任意两个开发者之间可以很容易的解决冲突。

• 离线工作。

缺点：

• 资料少（起码中文资料很少）。

• 学习周期相对而言比较长。

• 不符合常规思维。

• 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

目录

一、仓库创建& 提交代码

二、代码回滚

三、工作区和暂存区

四、撤销修改

五、删除操作

六、远程仓库

七、分支管理

八、多人协作

九、github使用

十、忽略特殊文件.gitignore

一、仓库创建& 提交代码

1、版本库创建

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

选择一个合适的地方，创建一个空目录：

$ mkdir git_trainning
$ cd git_trainning/

$ git init
Initialized empty Git repository in /Users/alex/git_trainning/.git/

这个目录默认是隐藏的，用ls -ah命令就可以看见。

2、git_trainning目录下（子目录也行）创建文件

$ vim first_git_file.txt

3、把文件添加到版本库

# 第一步:用命令git add告诉Git，把文件添加到仓库
$ git add first_git_file.txt
#第二步:告诉git你是谁
git config --global charlie@126.com
git config --global charlie
#可以通过git config --global --edit修改
# 第三步：提交,需要给文件添加一些修改说明
git commit
# 在命令行直接添加
$ git commit -m "change first"  

# 一次提交多个文件
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

二、代码回滚

1、先vim，修改内容后先别add，查看一下状态，会有提示

# 查看当前状态
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   first_git_file.txt

no changes added to commit (use "git add" and/or "git commit -a")

2、查看修改内容，输出中＋号绿色显示的就是修改或新增的内容，－号红色显示的就是去掉或被修改的内容

$ git diff first_git_file.txt
diff --git a/first_git_file.txt b/first_git_file.txt
index 2d13c2c..248d853 100644
--- a/first_git_file.txt
+++ b/first_git_file.txt
@@ -1,3 +1,4 @@
-first time using git, excited!
+First time using git, excited! update ...
 insert line here...
 第一次用git哈哈
+insert line again haha...

3、再次提交

$ git add . # .  代表把当前目录下所有改动的文件都提交到代码库
Alexs-MacBook-Pro:git_trainning alex$ git commit -m "commit changes"
[master 50ad6b5] commit changes
 Committer: Alex Li <alex@Alexs-MacBook-Pro.local>
 1 file changed, 1 insertion(+)

4、代码回滚

历史记录，在Git中，我们用git log命令查看：

$ git log
commit 445965781d1fd0d91e76d120450dd18fd06c7489
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 18:44:29 2016 +0800

    add new content

commit be02137bb2f54bbef0c2e99202281b3966251952
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:55:16 2016 +0800

    update again

commit 50ad6b526810bb7ccfea430663757ba2337b9816
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:46:51 2016 +0800

    commit changes

commit 621e6e44d04fa6a1cdc37826f01efa61b451abd1
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:42:50 2016 +0800

    commit my first git file

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：

$ git log --pretty=oneline
445965781d1fd0d91e76d120450dd18fd06c7489 add new content
be02137bb2f54bbef0c2e99202281b3966251952 update again
50ad6b526810bb7ccfea430663757ba2337b9816 commit changes
621e6e44d04fa6a1cdc37826f01efa61b451abd1 commit my first git file

看到的一大串类似3628164...882e1e0的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示。

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交be02137bb2f54bbef0c2e99202281b3966251952（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

现在，我们要把当前版本“add new content”回退到上一个版本“update again”，就可以使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at be02137 update again

只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个add new content的commit id是445965781d1fd0d91e76d120450dd18fd06c7489

，于是就可以指定回到未来的某个版本：

git reset --hard 4459657
HEAD is now at 4459657 add new content

版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到update again版本时，再想恢复到最新add new content的版本，就必须找到add new contentL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

$ git reflog
4459657 HEAD@{0}: reset: moving to 4459657
be02137 HEAD@{1}: reset: moving to HEAD^
4459657 HEAD@{2}: commit: add new content
be02137 HEAD@{3}: reset: moving to be02137bb
50ad6b5 HEAD@{4}: reset: moving to 50ad6b5

三、工作区和暂存区

1、工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的git_trainning文件夹就是一个工作区：

2、版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

四、撤销修改

1、git checkout -- file可以丢弃工作区的修改

$ git checkout -- readme.md

命令git checkout -- readme.md意思就是，把readme.md文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.md自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.md已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。　

2、在commit之前，你发现了问题，用git status查看一下，修改只是添加到了暂存区，还没有提交：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.md

Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：

$ git reset HEAD readme.md
Unstaged changes after reset:
M   readme.md

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

五、删除操作

Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test"
[master 03df00a] remove test
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.txt

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

$ git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

六、远程仓库

1、SSH加密

由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen

然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：

点“Add Key”，你就应该看到已经添加的Key

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

2、创建远程仓库

现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。

首先，登陆GitHub，然后，在右上角找到“New repository”按钮，创建一个新的仓库：

创建好的仓库：

目前，在GitHub上的这个oldboy_website仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

现在，我们根据GitHub的提示，在本地已有的git_trainning仓库下运行命令：

$ git remote add origin git@github.com:triaquae/oldboy_website.git ＃添加远程仓库
$ git push -u origin master #推到远程

The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes   #第一次推会出现，写yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
Counting objects: 20, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (20/20), 1.76 KiB | 0 bytes/s, done.
Total 20 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), done.
To git@github.com:triaquae/oldboy_website.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

此时刷新远程仓库页面， 就看到了你刚从本地推上来的代码了

从现在起，只要本地作了提交，就可以通过命令：

$ git push origin master

3、从远程库克隆　

首先，登陆GitHub，创建一个新的仓库，名字叫gitskills：

我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件；

现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

在本地找一个你想存放这个远程仓库的目录，然后在本地命令行用git clone 命令来克隆这个远程库

$ git clone git@github.com:triaquae/gitskills.git
Cloning into 'gitskills'...
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Checking connectivity... done.

$ cd gitskills/  #进入刚clone下来的目录
$ ls
README.md

你也许还注意到，GitHub给出的地址不止一个，还可以用https://github.com/triaquae/gitskills.git 这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

4、提示出错信息：fatal: remote origin already exists.

• 先输入$ git remote rm origin

• 再输入$ git remote add origin git@github.com:djqiang/gitdemo.git 就不会报错了

• 如果输入$ git remote rm origin 还是报错的话，error: Could not remove config section 'remote.origin'. 我们需要修改gitconfig文件的内容

• 找到你的github的安装路径，我的是C:\Users\ASUS\AppData\Local\GitHub\PortableGit_ca477551eeb4aea0e4ae9fcd3358bd96720bb5c8\etc

• 找到一个名为gitconfig的文件，打开它把里面的[remote "origin"]那一行删掉就好了

七、分支管理

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

1、创建与合并分支

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用git branch命令查看当前分支：

$ git branch
* dev
  master

git branch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，不能直接提交到master了，比如对readme.txt做个修改，加上一行，然后提交：

$ git add readme.txt
$ git commit -m "branch test"
$ git push origin dev

现在，dev分支的工作完成，我们就可以切换回master分支：

$ git checkout master
Switched to branch 'master'

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变；

首先要确定master上是最新的主库，更新一下本地的master:

$ git pull
Already up-to-date
# 表明已经是最新的了

现在，我们把dev分支的工作成果合并到master分支上：

$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |    1 +
 1 file changed, 1 insertion(+)

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快，当然，也不是每次合并都能Fast-forward。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was fec145a).

删除后，查看branch，就只剩下master分支了：

$ git branch
* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

2、解决冲突

准备新的feature1分支，继续我们的新分支开发：

$ git checkout -b feature1
Switched to a new branch 'feature1'

修改readme.txt最后一行，改为：

added this line from branch feature 1

在feature1分支上提交：

$ git add readme.txt
$ git commit -m "add feature"
$ git push origin featurel

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.

在master分支上把readme.txt文件的最后一行改为：

added this line from master

提交：

$ git add readme.txt
$ git commit -m "master update"
[master 400b400] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件；

我们可以直接查看readme.txt的内容：

#git study repo
Creating a new branch is quick.
<<<<<<< HEAD
added this line from master
=======
added this line from branch feature 1
>>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

#git study repo
Creating a new branch is quick.
added this line from master
added this line from branch feature 1

再提交：

$ git add readme.txt
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed

现在，master分支和feature1分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline
*   feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict
|\
| * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch
* | 743ccee30f3d74f1993f17e7312032b7399b1306 from master
|/
* edfbc29982927236596539e0f1971b0575f803c0 branch test
* 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page

3、分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往master分支上合并就可以了，每次合并之前要确保本地的master是最新的，输入git pull更新本地master，然后再把本地master和分支合并。

4、bug分支

在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，提交到bug分支：

$ git add readme.txt
$ git commit -m "fix bug 101"

修复完成后，切换到master分支，先更新本地master库，git pull，然后合并master和bug分支，如果还有冲突，继续对照修改，提交到master，最后删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

是时候接着回到dev分支干活了：

$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list查看，就看不到任何stash内容了，你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

八、多人协作

1、当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

$ git remote
origin

或者，用git remote -v 显示更详细的信息：

$ git remote -v
origin  git@github.com:triaquae/gitskills.git (fetch)
origin  git@github.com:triaquae/gitskills.git (push)　

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

2、推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

3 、抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

$ git clone git@github.com:triaquae/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0
Receiving objects: 100% (16/16), done.
Checking connectivity... done.

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch
* master

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

$ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

$ git add .
$ git commit -m "small updates"

[dev f1b762e] small updates
 2 files changed, 5 insertions(+), 1 deletion(-)
Alexs-MacBook-Pro:gitskills alex$ git push origin dev
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 438 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To git@github.com:triaquae/gitskills.git
   33ec6b4..f1b762e  dev -> dev

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送:

$ git add .
$ git commit -m "add Dog class"
[dev 7e7b1bf] add Dog class
 2 files changed, 7 insertions(+)

$ git push origin dev

To git@github.com:triaquae/gitskills.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:triaquae/gitskills.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again. #提示你了，先把远程最新的拉下来再提交你的
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推：

$ git pull
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com:triaquae/gitskills
   33ec6b4..f1b762e  dev        -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

$ git branch --set-upstream-to=origin/dev dev
Branch dev set up to track remote branch dev from origin.

再pull：

$ git pull
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
Auto-merging branch_test.md
CONFLICT (content): Merge conflict in branch_test.md
Automatic merge failed; fix conflicts and then commit the result.

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

$ git add .
$ git commit -m "merge & fix hello.py"
[dev 93e28e3] merge & fix hello.py

$ git push origin dev

Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 819 bytes | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To git@github.com:triaquae/gitskills.git
   f1b762e..93e28e3  dev -> dev

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin branch-name推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

九、github使用

1、如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页https://github.com/twbs/bootstrap，点“Fork”就在自己的账号下克隆了一个bootstrap仓库，然后，从自己的账号下clone：

git clone git@github.com:michaelliao/bootstrap.git

一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

小结

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

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

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

十、忽略特殊文件.gitignore

　　有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；

2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；

3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

举个例子：

假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa

最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。

使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：

$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.

如果你确实想添加该文件，可以用-f强制添加到Git：

$ git add -f App.class

或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：

$ git check-ignore -v App.class
.gitignore:3:*.class    App.class　　

Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

小结

• 忽略某些文件时，需要编写.gitignore；

• .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

以上文章大量参考或转载自: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000