版本控制的git和github仓库

版本控制很多。
所有的版本控制系统，只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等。而图片、视频这些二进制文件，没法跟踪文件的变化。不幸MS的Word格式是二进制格式。
不要用Windows自带的记事本编辑任何文本文件，他给每个文件开头添加了0xefbbbf。

CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。
SVN修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。
而git是有名的分布式版本控制系统。

集中式和分布式。
集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。

一、本地 安装和设置

1. 安装Git
$ sudo apt-get install git

2. 设置
$ git config –global user.name “Your Name”
$ git config –global user.email “email@example.com”

git config命令的–global参数表示这台机器上所有的Git仓库都会使用这个配置

二、 远程仓库 github

Git是分布式版本控制系统，同一个Git仓库可以分布到不同的机器上。
不过为了学Git先搭个服务器小题大作，有现成的GitHub的网站。只要注册一个GitHub账号，就可以免费获得Git远程仓库。
本地Git仓库和GitHub仓库之间的传输是通过SSH加密的。

1. 创建SSH Key
在用户目录下，看看有没有.ssh目录，如果有再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果也有，跳过。
如果没有，创建SSH Key：
$ ssh-keygen -t rsa -C “youremail@example.com”
这个Key也不是用于事目的所以也无需设置密码。
ok的话在用户目录里有.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

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

：NOTE：
不过在GitHub上免费托管的Git仓库，任何人都可以看到， 虽然只有自己才能修改。
如果不想让别人看到Git库，有两个办法，一个是交保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是自己的Git服务器，所以别人也是看不见的。

三、 本地创建版本库

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

1. 首先，选择一个合适的位置，创建空目录
$ mkdir gitdehaou1404
$ cd gitdehaou1404
当然，不一定必须在空目录下创建Git仓库，选择一个已经有东西的目录也是可以的。

2. 把这个目录变成Git可以管理的仓库
$ git init
当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的
NOTE: 不要手动修改这个目录里面的文件

四、创建新文件并提交

1. 创建文件或文件家
$ vi readme.txt
Git is a version control system.
Git is free software.

2. 添加新文件到仓库
$ git add readme.txt
注意，可反复多次添加多个文件
$ git status
On branch master
Initial commit
Changes to be committed:
(use “git rm –cached …” to unstage)
new file: readme.txt

3. 提交新文件到仓库
$ git commit -m “wrote a readme file”
[master (root-commit) b8996b7] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
执行成功后: 1个文件被改动,插入了2行.
NOTE: git commit命令-m后面输入的是本次提交的说明

4. 提交多个文件
Git添加多个文件也需要add和commit两步
$ echo file1 > file1.txt
$ echo file2 > file2.txt
$ echo file3 > file3.txt
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m “add 3 files.”
[master dab17ea] add 3 files.
3 files changed, 3 insertions(+)
create mode 100644 file1.txt
create mode 100644 file2.txt
create mode 100644 file3.txt

五、 修改并提交老文件

1. 修改readme.txt文件
$ vi readme.txt
Git is a distributed version control system.
Git is free software.

2. 仓库当前的状态
$ git status
# On branch master
# Changes not staged for commit:
# (use “git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: readme.txt
#
# no changes added to commit (use “git add” and/or “git commit -a”)

命令告诉我们：
readme.txt被修改过了，但还没有准备提交的修改。

3. 查看修改了什么内容
$ git diff readme.txt
# diff –git a/readme.txt b/readme.txt
# index 46d49bf..9247db6 100644
# — a/readme.txt
# +++ b/readme.txt
# @@ -1,2 +1,2 @@
# -Git is a version control system.
# +Git is a distributed version control system.
# Git is free software.

可以看到：
第一行添加了一个“distributed”单词。

4. 提交修改的文件到仓库
$ git add readme.txt

5. 当前仓库的状态
$ git status
# On branch master
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# modified: readme.txt
#

这是执行commit之前的仓库的状态，
告诉我们将要被提交的修改包括readme.txt … 等文件

6. 提交
$ git commit -m “add distributed”
# [master ea34578] add distributed
# 1 file changed, 1 insertion(+), 1 deletion(-)

7. 仓库的当前状态
$ git status
# On branch master
# nothing to commit (working directory clean)

当前没有需要提交的修改，
而且，工作目录是干净。

8. 再一次，第二次修改
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
提交
$ git add readme.txt
$ git commit -m “append GPL”
[master 3628164] append GPL
1 file changed, 1 insertion(+), 1 deletion(-)

9. 历史记录日志
git log命令显示从最近到最远的提交日志，
$ git log

commit 6dee0b8a2969c54a4e165fa3503a961b92e26c9f
Author: dehaou1404
Date: Tue Jan 9 09:50:09 2017 +0800

add info about desc

commit 0cec593eafb0deee08fe2064ef92f39da0e2d287
Author: dehaou1404
Date: Sat Feb 25 15:21:20 2016 +0800

remove test.txt

commit 4bd697ee49e47a526534abcd3bf8e2436f1ac7b8
Author: dehaou1404
Date: Sat Feb 25 15:20:11 2016 +0800

add test.txt

如果嫌输出信息太多了，可以加上–pretty=oneline参数：
$ git log –pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
类似3628164…882e1e0的是commit id

六、前跳和后跳

在Git中用HEAD表示当前版本，上一个版本是HEAD^，上上个版本是HEAD^^，往上100个版本是HEAD~100。

用git log可以查看提交历史，以便确定要回退到哪个版本。
用git reflog查看命令历史，以便确定要回到未来的哪个版本。

1. 回退到老版本
把当前版本“append GPL”回退到上一个版本“add distributed”
$ git reset –hard HEAD^
HEAD is now at ea34578 add distributed
$ cat readme.txt
Git is a distributed version control system.
Git is free software.

2. 再恢复到新版本
找回新版本的commit id：
$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file

回复到新版本：
$ git reset –hard 3628164
HEAD is now at 3628164 append GPL

七、 工作区和暂存区

* 工作区（Working Directory）：
就是在电脑里能看到的目录，比如gitlocal文件夹

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

* 暂存区（index或者叫stage）：
版本库里有很多东西，其中最重要的就是暂存区，还有自动创建的第一个分支master以及指向master的指针HEAD。
暂存区是Git非常重要的概念，弄明白了暂存区就明白了Git的很多操作到底干了什么。

把文件往Git版本库里添加的两步：
第一步，是用git add把文件添加进去，实际上是把文件修改添加到暂存区；
第二步，是用git commit提交更改，实际上是把暂存区的所有内容提交到当前分支。
创建Git版本库时自动创建的是master分支，所以git commit就是往master分支上提交更改。
简单理解为：需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

例如：
* 先修改一个文件readme.txt
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
* 再新增一个文件LICENSE.cc
$ vi LICENSE.cc
something LICENSE
* 查看一下状态
$ git status
# On branch master
# Changes not staged for commit:
# (use “git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: readme.txt
#
# Untracked files:
# (use “git add …” to include in what will be committed)
#
# LICENSE
no changes added to commit (use “git add” and/or “git commit -a”)

说明：
readme.txt被修改了，而LICENSE还从来没有被添加过、所以它的状态是Untracked。

* 添加
$ git add readme.txt
$ git add LICENSE
* 再查看状态
$ git status
# On branch master
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# new file: LICENSE
# modified: readme.txt

git add命令，
实际上就是把要提交的所有修改放到暂存区（Stage）

*然后体提交，
执行git commit就可以一次性把暂存区的所有修改提交到分支
$ git commit -m “understand stage works”
[master 27c9860] understand stage works
2 files changed, 675 insertions(+)
create mode 100644 LICENSE

九、 管理修改

Git跟踪并管理的是修改、而非文件。
什么是修改？新增了一行，这就是一个修改。删除了一行，也是一个修改。

* 第一次修改
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

* 第一次添加
$ git add readme.txt

* 状态，等待提交
$ git status
# On branch master
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# modified: readme.txt
#

* 不提交，

* 第二次修改
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files………

* 这里提交：
$ git commit -m “git tracks changes”
[master d4f25b6] git tracks changes
1 file changed, 1 insertion(+)

* 状态
$ git status
# On branch master
# Changes not staged for commit:
# (use “git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: readme.txt
#
no changes added to commit (use “git add” and/or “git commit -a”)
怎么第二次的修改没有被提交？！

回顾一下操作过程：第一次修改 -> git add -> 第二次修改 ->没有做git add-> git commit 。
Git管理的是修改，当用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

查看工作区和版本库里面最新版本的区别：
$ git diff HEAD — readme.txt
diff –git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
— a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.
可见第二次修改确实没有被提交。

所以Git是如何跟踪修改的：
每次修改如果不add到暂存区，那就不会加入到commit中。
怎么提交第二次修改呢？
可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改再git commit，就相当于把两次修改合并后一块提交： 第一次修改 -> git add -> 第二次修改 -> git add -> git commit

十、 撤销修改

git checkout — file可以丢弃工作区的修改
注意：
git checkout — file命令中的–很重要。 没有–，就变成了“切换到另一个分支”的命令。

这是把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改以后还没有被放到暂存区，现在，撤销修改就回到和版本库里一模一样的状态。
一种是readme.txt已经添加到暂存区，之后又作了修改，现在，撤销修改就回到添加到暂存区后的状态。再执行前一步。
总之，就是让这个文件回到最近一次git commit或git add时的状态。

例如：
修改了readme.txt，添加了一行：
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My change XXXXXX.

$ git checkout — readme.txt
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
可见没有改变。

再例如：
不但修改了，而且git add到暂存区了
$ vi readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My change ZZZZZZZZZZ.

$ git add readme.txt
但是在commit之前发现了这个问题
$ git status
# On branch master
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# modified: readme.txt
#

git reset HEAD file可以把暂存区的修改撤销掉，重新放回工作区。<------ $ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt $ git status # On branch master # Changes not staged for commit: # (use "git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: readme.txt
#
no changes added to commit (use “git add” and/or “git commit -a”)
查看一下，现在暂存区是干净的，工作区有修改，SO 丢弃工作区的修改

$ git checkout — readme.txt
$ git status
# On branch master
nothing to commit (working directory clean)

总结：
场景1：改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout — file。
场景2：不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，要分两步:第一步git reset HEAD file回到场景1，第二步按场景1操作git checkout — file。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
场景4：推送到远程库了，&*……（&）——（@#

十一、 删除文件

创建一个新文件test.txt
$ vi test.txt
something test.txt
添加到暂存
$ git add test.txt
提交到Git
$ git commit -m “add test.txt”
[master 94cdc44] add test.txt
1 file changed, 1 insertion(+)
create mode 100644 test.txt

然后呢，直接在文件管理器中把没用的文件删了，或者用rm命令删了：
$ rm test.txt

这时，Git知道删除了文件，因此工作区和版本库就不一致了
看状态
$ git status
# On branch master
# Changes not staged for commit:
# (use “git add/rm …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# deleted: test.txt
#
no changes added to commit (use “git add” and/or “git commit -a”)
git status命令会立刻告诉哪些文件被删除了。

此时有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉 & 并且git commit：
$ git rm test.txt
rm ‘test.txt’
$ git commit -m “remove test.txt”
[master d17efd8] remove test.txt
1 file changed, 1 deletion(-)
delete mode 100644 test.txt
现在文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有所以可以很轻松地把误删的文件恢复到最新版本：
$ git checkout — test.txt
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

十二、 添加远程库

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

1. 登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库。 在Repository name填入dehaou1404，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库。

目前，在GitHub上的这个gitlocal仓库还是空的，GitHub告诉我们
可以从这个仓库克隆出新的仓库:

echo “# dehaou1404” >> README.md
git init
git add README.md
git commit -m “first commit”
git remote add origin https://github.com/zdhtest/dehaou1404.git
git push -u origin master

–or,也可以把一个已有的本地仓库与之关联，然后把本地仓库的内容推送到GitHub仓库。
git remote add origin https://github.com/zdhtest/dehaou1404.git
git push -u origin master

2. 现在根据GitHub的提示，在本地的gitdehaou1404仓库目录下运行命令，关联一个远程库：
$ git remote add origin git@github.com:zdhtest/dehaou1404.git
dehaou1404.git 是 github.com 用户名, 添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

3. 下一步，就可以把本地库的所有内容推送到远程库上：
用git push命令把本地库的内容推送到远程，实际上是把当前分支master推送到远程。
$ git push -u origin master
Counting objects: 28, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (28/28), 2.10 KiB | 0 bytes/s, done.
Total 28 (delta 11), reused 0 (delta 0)
remote: Resolving deltas: 100% (11/11), done.
To git@github.com:zdhtest/dehaou1404.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，因此Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样

if first time:
The authenticity of host ‘github.com (192.30.253.112)’ can’t be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘github.com,192.30.253.112’ (RSA) to the list of known hosts.

4. 从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在就拥有了真正的分布式版本库

总结：
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

十三、 从远程库克隆

前面都是先有本地库，后有远程库的时候，关联远程库。
这里先创建好了远程库，然从远程库克隆到达本地。

1. 陆GitHub，创建一个新的仓库，名字叫HTML5-Example
勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。

2. 下一步是用命令git clone克隆一个本地库
$ git clone git@github.com:zdhtest/HTML5-Example.git
Cloning into ‘HTML5-Example’…
remote: Counting objects: 48, done.
remote: Total 48 (delta 0), reused 0 (delta 0), pack-reused 48
Receiving objects: 100% (48/48), 373.64 KiB | 23.00 KiB/s, done.
Resolving deltas: 100% (10/10), done.
Checking connectivity… done.
$ cd gitskills
$ ls

十四、 创建与合并分支
分支在实际中有什么用呢？假设准备开发一个新功能，但是需要两周才能完成，第一周写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
有了分支就不用担心了。先创建了一个属于自己的分支，别人看不到还继续在原来的分支上正常工作，而在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人。
Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点
每次提交，master分支都会向前移动一步，这样，随着不断提交，master分支的线也越来越长

当创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变

假如在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后就剩下了一条master分支

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’

2. 用git branch命令查看当前分支
$ git branch
* dev
master
git branch命令会列出所有分支，当前分支前面会标一个*号

3. 然后就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：
Creating a new branch is quick.
然后提交：
$ git add readme.txt
$ git commit -m “branch test”
[dev fec145a] branch test
1 file changed, 1 insertion(+)
现在，dev分支的工作完成，就可以切换回master分支：
$ git checkout master
Switched to branch ‘master’
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变

4. 把dev分支的工作成果合并到master分支上
$ git merge dev
Updating d17efd8..fec145a
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

5. 合并完成后就可以放心地删除dev分支了：
$ git branch -d dev
Deleted branch dev (was fec145a).
删除后，查看branch，就只剩下master分支了：
$ git branch
* master

十五、解决冲突

准备新的feature1分支，继续新分支开发：
$ git checkout -b feature1
Switched to a new branch ‘feature1’

修改readme.txt最后一行为：
Creating a new branch is quick AND simple.

在feature1分支上提交：
$ git add readme.txt
$ git commit -m “AND simple”
[feature1 75a857c] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：
$ git checkout master
Switched to branch ‘master’
Your branch is ahead of ‘origin/master’ by 1 commit.
自动提示我们当前master分支比远程的master分支要超前1个提交。

在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.

提交：
$ git add readme.txt
$ git commit -m “& simple”
[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也可以告诉我们冲突的文件：
$ git status
# On branch master
# Your branch is ahead of ‘origin/master’ by 2 commits.
#
# Unmerged paths:
# (use “git add/rm …” as appropriate to mark resolution)
#
# both modified: readme.txt
#
no changes added to commit (use “git add” and/or “git commit -a”)

我们可以直接查看readme.txt的内容：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. >>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容

我们修改如下后保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m “conflict fixed”
[master 59bc1cb] conflict fixed
现在，master分支和feature1分支变成了下图所示

用带参数的git log也可以看到分支的合并情况：
$ git log –graph –pretty=oneline –abbrev-commit
* 59bc1cb conflict fixed
|
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test
…

最后，删除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 75a857c).

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本

十六、 忽略特殊文件

有些时候必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files …
Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件
忽略自己的带有敏感信息的配置文件，比如存放口令的配置文件。

一个完整的.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

十七、 小结

1. 转到在项目所在顶层目录

2. 该目录变成Git可以管理的仓库
$ git init
3. 添加文件
$ git add readme.txt or,
$ git add .
4. 提交到仓库
$ git commit -m “a commect”

5. 登陆GitHub.com, 创建一个新的仓库XXX

6. 关联远程库
$ git remote add origin git@github.com:zdhtest/XXX.git
7. 把本地库的所有内容推送到远程库
$ git push -u origin master

8. 此后随时把本地master分支的最新修改推送至GitHub
$ git push origin master

十八、 利用Dropbox实现Git私有仓库

Github免费用户无法实现私有仓库， 可以用Dropbox免费账户的2G空间来托管代码，
从而个人代码库可以同步到Dropbox并且在多台电脑上同步，实现云备份。

安装Dropbox：
$ sudo apt-get update
$ sudo apt-get install nautilus-dropbox
$ nautilus –quit
$ dropbox start -i

然后在~/Dropbox下创建一个gits目录用于存放各个项目的版本库，当然可以将整个Dropbox目录都用于托管，
不过大多数应该是用Dropbox备份比较好，便于管理其他内容的存储相区别。
$ cd ~/Dropbox
$ mkdir gits

下面是某个名为your-project的项目的部署过程：

1. 在本机这个your-project目录下完成创建、添加、提交：
$ cd your-project
$ git init
$ git add *
$ git commit -m “init commit”

2. 在本机~/Dropbox/gits创建一个空白的bare裸仓库版本库
现在为本地工作拷贝创建一个空的版本库作为Git远程版本库，除了这是在本地操作以外，这本质上和用Github或者其他版本库托管网站的工作方式类似。
$ cd ~/Dropbox/gits
$ mkdir your-project.git
$ cd your-project.git
$ git –bare init

3. 在本机这个your-project目录下添加remote origin并且push到“所谓远程的”Dropbox版本库
每次同步都会被Dropbox进程自动检测到改变并自动同步到Dropbox服务器
$ cd your-project
$ git remote add origin ~/Dropbox/gits/your-project.git
$ git push origin master
ok

NOTE：
只适用于单用户的私人项目.
为什么不直接将Git的代码库直接放到Dropbox目录呢，原因是这样一边开发一边同步很可能会产生冲突，而文描述的方式则不会产生这种冲突。