我的Git总结
Git基础
1.Git:分布式的版本控制系统
分布式和集中式最大的区别就是它没有中央服务器这么一说，每台电脑都是一个服务器，每台电脑都拥有一个完整的版本库，谁修改了就把新的数据推送到其他电脑上，如果某台电脑挂掉了，没事，从别的电脑上拷贝一个出来就搞定
Git 操作命令
git init --- 使用当前目录作为Git仓库
git init newrepo --- 使用指定目录作为Git仓库
初始化后，会在新建的仓库下出现一个.git的目录，所有 Git 需要的数据和资源都存放在这个目录中
eg:
mkdir test
cd test
git init
将文件加入版本库，使用 git add 命令告诉 Git 开始对这些文件进行跟踪，然后提交
$ git add *.c --- 将 .c 结尾的文件全部新增到版本库
$ git add README
$ git commit -m '初始化项目版本' --- 提交文件时，一定要加 -m 操作说明
$ git add --- 添加当前项目的所有文件，将想要快照的内容写入缓存区
git clone --- 从git仓库中拷贝项目
git clone --- 从git仓库中拷贝项目到指定目录
eg:
$ git clone git://github.com/schacon/grit.git
$ git status <-s> --- 查看项目的当前状态
$ git commit --- git add 是将想要快照的内容写入缓存区，git commit将缓存区内容添加到仓库中
$ git commit -a --- 直接提交目录下已修改的文件到仓库
$ git reset HEAD -- filename --- 取消已缓存的内容 filename
2.Git基础
1.安装Windows下的Git后，出现2个启动程序：
Git Bash Unix Shell命令窗口
Git GUI Windows操作界面
2.设置全局的用户名和Email --- 打开Git Bash
git config --global user.name "Jay"
git config --global user.email "[email protected]"
3.Git 基本概念
分支(branch) 一个分支，即：一个独立拥有自己历史版本信息的代码线，可以从已有代码中生成一个新分支，这个分支与其余的分支完全独立。
默认分支叫 master， 用于可以选择一个分支，选择一个分支叫 Checkout
提交(commit) 提交更改到Git库中，它将创建一个新的提交对象，这个提交对象会有一个新版本的唯一标识，本次修订后，可以检索(eg:查看旧版本源码)，
每个提交对象中都会包含修改者和提交者，修改者和提交者可以是不同的人
头(HEAD) 象征性的参考，最常用以指向当前选择的分支
仓库(Repository) 仓库包含了随着时间推移和各种不同的分支和标签不同版本历史，
在Git仓库的每个副本是一个完整的信息库。你可以从仓库中获取你的工作副本。
修订(Revision) 表示代码的一个版本状态
标记(Tags) 某个分支某个特定时间点的状态，通过标记，可方便的切换到标记时的状态
URL 仓库所在位置
工作区(Working Tree) 工作区包含了仓库的工作文件，可以修改的内容和提交更改作为新的提交到仓库
暂存区(Staging area) 工作区用来提交更改(commit)前可以暂存工作区的变化，工作区未commit之前的改变
暂存区包含了工作区的一系列更改快照，这些快照可以用来创建新的提交
索引（Index） 索引是暂存区的另一种术语。
工作区，暂存区，版本库的关系
工作区 -- 添加选择的改变 ( git add ) --> 暂存区 -- 提交改变 ( git commit ) --> 版本库
4.常用的Git指令
add 添加文件到索引(暂存区)
branch 列出、创建、删除分支
checkout 从仓库拉取代码到工作区
clone 克隆一个仓库到指定目录
commit 提交更改到仓库
diff 查看两次提交，或工作区直接的不同
fetch 从另一个仓库下载内容
init 创建一个空的Git仓库，或重新初始化一个已存在的Git仓库
log 查看提交日志
merge 合并分支
pull 拉取更新
push 推送更新
rebase 主要用在从上游分支获取最新commit信息，并有机的将当前分支和上有分支进行合并 参考：http://gitbook.liuhui998.com/4_2.html
reset 回退到某个指定版本
status 查看工作区状态
tag 列出、创建、删除 标识tag
5.常见的Git操作
1.仓库操作
1.创建仓库
#进入d盘目录
$ cd /d
#创建JackyGit文件夹
$ mkdir JackyGit
#进入JackyGit文件夹
$ cd JackyGit
#显示当前所在路径
$ pwd
#初始化当前目录作为Git仓库
$ git init
Initialized empty Git repository in d:/JackyGit/.git/
2.添加文件到仓库 -- 先进入仓库
mkdir jay
cd jay
touch test.txt #创建文件
echo test > test.txt #写入内容
3.查看Git仓库状态
git status
4.增加文件到暂存区
#增加所有文件到暂存区
git add .
说明： add . 将当前路径所有文件都提交到暂存区
add file 将指定文件提交到暂存区
5.提交更改
--- git commit -m "提交信息"
git commit -m "init files"
6.再次查看状态
$ git status
On branch master
nothing to commit, working directory clean
2.操作项目
1.查看操作日志
$ git log
commit 162aac88fef714a1ad60b0c98f040163dd895f5f
Author: Jay He <[email protected]>
Date: Thu Nov 3 15:08:05 2016 +0800
init Files
2.修改项目内容
$ echo "Hello Test" > test1.txt
3.查看当前状态
$ 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: test1.txt
4.提交修改
--- git commit -a -m "提交信息" 该命令，可省掉放入暂存区的操作，注解提交
$ git commit -a -m "直接提交"
5.查看操作日志
$ git log --pretty=oneline #单行显示，只显示版本号和备注
62d298b578aea3429617e0610b50329004479eaf 直接提交
162aac88fef714a1ad60b0c98f040163dd895f5f init Files
6.比较版本 --- git diff 用于比较上次提交和当前版本的差异
#修改本地版本的内容
$ echo "HelloGit" > test.txt
#使用git diff查看差异，可以看到testtest被删除了，而HelloGit被添加了
$ git diff
diff --git a/jay/test.txt b/jay/test.txt
index 5b3b4a7..84fab2a 100644
--- a/jay/test.txt
+++ b/jay/test.txt
@@ -1 +1 @@
-testtest
+HelloGit
7.提交修改，并打开Git GUI界面
#提交所有修改
$ git add . && git commit -m "提交修改"
#打开GUI界面
$ gitk --all
8.修改提交信息
--- git commit --amend -m "修改的提交信息" ： 修改上次提交的信息
git commit --amend -m "修改了上次提交的信息"
9.删除项目内容
rm data01
git add . && git commit -m "删除了test1.txt"
3.版本管理
1.版本回退
#查看从项目开始到现在做了什么操作
$ git log --pretty=oneline
e5da0b55510ef348ba96398be7978fca7751feed delete test1
6f6575694f931a3b509dd0a01af095495df9b089 delete test1.txt
04e8999e0281998c508e110b51d71827a0e28a00 删除
3e2356cc9babadd7e0b81c228c1340fe3421401b 修改了上次提交的信息
62d298b578aea3429617e0610b50329004479eaf 直接提交
162aac88fef714a1ad60b0c98f040163dd895f5f init Files
如果不想移除 test1.txt了，可用git reset进行版本回退，
git用HEAD表示当前版本，HEAD^，表示上一个版本，HEAD^^表示上上一个版本，HEAD~100表示往前100个版本
#回退到上一个版本
$ git reset --hard HEAD^
#回退到这之前的第2个版本
$ git reset --hard HEAD~2
说明：
1.--hard参数，会把源码也给推送到指定版本，不用--hard，源码不会修改，只会回退，
即：--hard会用指定版本覆盖现有源码，而不用--hard，源码不会更改，只是回退
2.reset只对本地仓库有效，对远程仓库无效
如何回退远程版本？
1.先不要在本地reset，而是先创建一个分支old_master，并切换到old_master分支
2.push old_master分支到远程仓库
3.在old_master分支上reset版本，并删除本地的master分支和远程的master分支
4.创建本地分支master，推送到远程分支master，此时远程分支会新建master
5.删除本地old_master分支和远程old_master分支
注意：以上操作较危险，谨慎处理！！！
2.版本选择
--- git reset --hard 版本号
eg:
#查看版本提交信息
$ git log --pretty=oneline
7e0b3a80e57d32b703681f7da332febeb2dc8d59 test1
62d298b578aea3429617e0610b50329004479eaf 直接提交
162aac88fef714a1ad60b0c98f040163dd895f5f init Files
#选择第一个版本
$ git reset --hard 7e0b3a80e57d32b703681f7da332febeb2dc8d59
HEAD is now at 7e0b3a8 test1
注意：
版本号可用不用完全输入，输入前几个git就会帮你找到，也不能太少，太少可能会找出多个
提醒：
如果git bash被关掉了，找不到版本号，可用 git reflog查看每一次的操作记录
#显示每次操作记录，然后就可以用reset所以选择版本了
$ git reflog
3.撤销修改
1.工作区 git checkout -- file 撤销对文件file的改动(修改、删除)
#修改test.txt内容
$ echo "Bye SVN" > test.txt
#查看git状态
$ git status
#想撤销修改、删除
$ git checkout --file test.txt
2.暂存区
必须先使用git reset HEAD file 把暂存区的修改撤回到工作区的修改，
然后再执行工作区的撤销修改操作 git checkout -- file
#修改test.txt内容
$ echo "Bye SVN" > test.txt
#提交到暂存区
$ git
$ git checkout --file test.txt
3.已提交到版本库
使用reset回退功能即可
4.远程仓库操作
--- 远程仓库：用来把Git仓库托管到互联网，本地网络或本机中
0.Github远程仓库操作
参考：http://www.cnblogs.com/tugenhua0707/p/4050072.html
1.创建SSH Key ， 在用户主目录下，生成 .ssh 目录，包含id_rsa(私钥)和id_rsa.pub(公钥)这两个文件，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人
ssh-keygen -t rsa -C "[email protected]"
注意：
如果本机已经存在 .ssh ，可以在创建时，选择一个密钥文件，用于存放公钥和密钥
2.添加SSH Key到github
登录github，打开sittings中的SSH Keys页面，点击 New SSH Key，填上任意title，在Key文本框里黏贴id_rsa.pub文件的内容
3.添加远程仓库
将本地的Git仓库和github上创建的Git仓库进行远程同步，样github的仓库可以作为备份，又可以其他人通过该仓库来协作
1.登录github，新建仓库 --- 右上角(+),点击 "New repository",新建仓库
在Repository name填入gittest1，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库
注意：
在github上，新创建的gittest1仓库是空的，
可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库
2.关联本地git仓库和github仓库 --- 这里关联本地的 jay仓库 和 gittest1仓库
进入本地jay仓库，执行命令
$ git remote add origin https://github.com/jayfeihe/gittest1.git
说明：
每个github仓库都有独立的github地址：1.HTTPS 2.SSH
3.推送本地库内容到远程仓库 --- 把本地master分支的最新修改推送到github上
$ git push origin master
4.从远程仓库克隆 --- 使用HTTPS地址
$ git clone https://github.com/jayfeihe/gittest1.git
5.提交本地文件到远程仓库
eg:
#创建新文件
$ touch remote.txt
#提交给工作区
$ git add .
#提交到本地库
$ git commit -m "commit to local repository"
#推送到远程库
$ git push https://github.com/jayfeihe/gittest1.git
注意：
推送给github仓库时，需要填写github的账户密码
1.创建本地远程仓库 git clone --bare
#1个点表示当前目录，2个点表示父目录 --- 为demo1仓库，建立一个本地远程仓库demo2
$ git clone --bare . ../demo2/remote-demo1.git
Cloning into bare repository '../demo2/remote-demo1.git'...
done.
2.推送更新到远程仓库
参考：
http://blog.csdn.net/column/details/jacky-git.html
http://www.cnblogs.com/itech/p/5188932.html
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
3.添加远程仓库
4.查看远程仓库信息
5.克隆仓库
6.Push(推送更新)和Pull(拉取更新)
7.移除远程仓库
5.创建和合并分支
分支： Git把每次提交都串成一条时间线，这条时间线就是一个分支
主分支：默认的Git分支，又叫 master分支
HEAD严格来说不是指向提交，而是指向mater，master才是指向提交的，HEAD指向的就是当前分支
1.创建分支
#创建dev分支，并切换到dev分支
$ git checkout -b dev
# 查看当前分支
$ git branch
说明：
1.git checkout 命令加上 –b参数表示创建并切换，相当于如下2条命令
git branch dev //创建dev分支
git checkout dev //切换到dev分支
2.git branch 查看分支，会列出所有分支，当前分支会添加一个星号
eg:
创建dev分支，并在dev分支中添加README文件
#创建并切换分支到dev
$ git checkout -b dev
#查看当前分支
$ git bransh
#在dev分支添加README文件
$ touch README
#提交到本地工作区
$ git add README
#提交到本地仓库
$ git commit -m "dev分支添加README文件"
#将当前分支推送到远程仓库
$ git push https://github.com/jayfeihe/gittest1.git
2.切换分支
#切换到branch_name分支
$ git checkout branch_name
3.合并分支
git merge branch_name --- 合并指定分支内容到当前分支上
eg:
#将dev分支内容合并到master分支 --- 在master分支上执行下面命令！！！
$ git merge dev
4.删除分支
git branch -d branch_name
eg:
#合并完成后，就可以删除dev分支了
$git branch -d dev
5.分支操作命令总结：
查看分支：git branch
创建分支：git branch name
切换分支：git checkout name
创建+切换分支：git checkout –b name
合并某分支到当前分支：git merge name
删除分支：git branch –d name
6.冲突解决
eg:
分支fenzhi1中创建一个readme.txt并添加内容，
分支master中创建一个readme.txt并添加内容，
这时master合并fenzhi1时，会有冲突
$ git merge fenzhi1
Auto-merging jay/readme.txt
CONFLICT (add/add): Merge conflict in jay/readme.txt
Automatic merge failed; fix conflicts and then commit the result.
操作步骤：
1.创建fenzhi1，并新增readme.txt文件，然后提交到本地库
$ git checkout -b fenzhi1
#添加内容8888888
$ vi readme.txt
$ git add reame.txt
$ git commit -m "fenzhi1分支添加readme.txt文件"
2.切换到master分支，并新增readme.txt文件，然后提交到本地库
$ git checkout master
#添加内容11111111
$ vi readme.txt
$ git add reame.txt
$ git commit -m "master分支添加readme.txt文件"
3.master分支合并fenzhi1， 报冲突 conflict
$ git merge fenzhi1
Auto-merging jay/readme.txt
CONFLICT (add/add): Merge conflict in jay/readme.txt
Automatic merge failed; fix conflicts and then commit the result.
说明：
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，
<<>>>>fenzhi1 指fenzhi1上修改的内容
eg:
$ cat readme.txt
<<<<<<< HEAD
11111111
=======
88888888
>>>>>>> fenzhi1
说明：
======= 之前的是HEAD分支内容，之后的是fenzhi1内容
4.解决冲突
修改冲突文件，然后提交
eg:
#将readme.txt文件内容改为 8888888,然后再提交即可
#1.解决冲突，修改文件内容
$ vi readme.txt
#2.添加冲突文件，并提高到本地库
$ git add readme.txt
$ git commit -m "conflict fixed"
$ git status
7.查看分支合并情况
git log
操作远程仓库的主分支和dev分支：
1.克隆远程分支
$ mkdir test
$ cd test
$ git clone https://github.com/jayfeihe/gittest1.git
2.查看当前分支
$ git branch
$ git branch -a 显示所有分支
3.切换到dev分支
$ git checkout dev
#如果无法切换，可先本地创建一个dev分支，然后通过git pull origin dev方式同步远程dev分支
4.修改内容，并提交到本地dev分支
$ touch dev-tag.txt //创建文件
$ git add . //添加文件到工作区
$ git commit -m "add file dev-tag.txt" //提交到本地仓库(dev分支)
5.提交修改到远程仓库dev分支
$ git remote
$ git push origin dev
6.合并dev到本地master
$ git checkout master
$ git merge dev
7.master提交到远程仓库
$ git push origin
8.master将dev-tag.txt修改为master-tag.txt，并提交到远程master分支
$ git checkout master
$ mv dev-tag.txt master-tag.txt
$ git status
$ git add .
$ git commit -m "remove dev-tag.txt ,add master-tag.txt"
$ git push origin
在弹出框中填写自己的github账号和密码
注意：添加和删除远程分支 --- 已经连接过github
1.添加远程仓库分支
$ git branch branch1
$ git checkout branch1
$ git branch
$ git push origin branch1
2.删除远程仓库分支
$ git push origin :branch1
3.克隆远程分支到本地
$ git checkout -b branch1 origin/branch1
8.分支管理策略
分支策略：
首先master主分支应该是非常稳定的，也就是用来发布新版本，一般情况下不允许在上面干活，干活一般情况下在新建的dev分支上干活，
干完后，比如上要发布，或者说dev分支代码稳定后可以合并到主分支master上来！！！
git 在合并分支时，默认使用 "Fast froward"模式，这种模式下，删除分支后，会丢掉分支信息，
可以使用参数 --no-ff 来禁止 "Fast froward"模式
eg:
创建一个dev分支。
修改readme.txt内容。
添加到暂存区。
切换回主分支(master)。
合并dev分支，使用命令 git merge –no-ff -m “注释” dev
查看历史记录
#dev分支上的操作
$ git checkout -b dev
$ git add readme1.txt
$ git commit -m "add merge"
#master分支上的操作
$ git checkout master
$ git merge --no-ff -m "merge with no-ff" dev
$ git branch -d dev
$ git log
说明：
1. 查看分支日志： 使用 --no-ff 参数，删除dev分之后，被删除的分支信息在log中仍然存在
2. 分支策略：
首先master主分支应该是非常稳定的，也就是用来发布新版本，一般情况下不允许在上面干活，干活一般情况下在新建的dev分支上干活，
干完后，比如上要发布，或者说dev分支代码稳定后可以合并到主分支master上来！！！
9.bug分支
Git中分支很强大，每个bug都可以通过一个临时分支来修复，修复完成后，合并该临时分支，然后删除临时分支即可
10.多人协作
当你从远程库克隆时候，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且远程库的默认名称是origin
1.查看远程库信息
git remote ---- 查看远程库信息
git remote -v ---- 查看远程库的详细信息
2.推送分支
推送分支就是把该分支上所有本地提交到远程库中，推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上
1.推送到master分支
git checkout master
git push origin master
2.推送到其他分支 dev
git push origin dev
特别注意：
那些分支需要推送？
1.master分支时主分支，要时刻与远程同步
2.一些修复bug分支，不需要推送到远程，可以先合并到主分支，然后把主分支master推送到远程去
3.抓取分支
git clone git远程库地址(HTTPS和SSH2种方式)
eg:
#新建或选择指定目录，执行命令
git clone https://github.com/jayfeihe/gittest1.git
eg:
#员工1 把dev分支推送到远程仓库
$ git checkout dev
$ git push origin dev
#员工2 新建testgit2目录，在该目录中，克隆远程仓库,切换到dev分支
$ mkdir testgit2
$ git clone https://github.com/jayfeihe/gittest1.git
#创建远程库origin/dev分支到本地dev分支，并切换到dev分支
$ git checkout -b dev origin/dev
#修改dev中的文件，并提交，然后把dev分支推送到远程库
$ vi readme.txt
xxxxx
$ git add readme.txt
$ git commit -m "readme.txt 增加xxxxx内容，推送给远程库dev分支"
#把3现在的dev分支推送到远程去
$ git push origin dev
注意：
1.如果推送到远程有冲突，解决方法：
git pull 把最新的提交从origin/dev抓下来，然后在本地合并，解决冲突，再推送
2.多人协作的一般模式：
首先，可以试图用git push origin branch-name推送自己的修改.
如果推送失败，则因为远程分支比你的本地更新早，需要先用git pull试图合并。
如果合并有冲突，则需要解决冲突，并在本地提交。再用git push origin branch-name推送。 冲突解决
1.多人协作冲突
如果多人同时修改了同一个文件，那会出现什么样的结果呢？我们试着这么做。
（1）修改jackygit2
在jackygit2中修改jackydata01，提交修改并推送到远程仓库（这里使用本地远程仓库）。正常，没问题。
- #切换到jackygit2本地库，这是远程仓库那节建立的，从本地远程仓库克隆而来
- $ cd ../jackygit2
- #修改jackygit2/Jackydata01
- $ echo "It's modified in jackygit2" > jackydata01
- #提交jackygit2的修改
- $ git commit -a -m "jackygit2 modify"
- [master 15a6406] jackygit2 modify
- 1 file changed, 1 insertion(+), 1 deletion(-)
- #推送到远程仓库origin
- $ git push origin
- Counting objects: 5, done.
- Delta compression using up to 2 threads.
- Compressing objects: 100% (2/2), done.
- Writing objects: 100% (3/3), 283 bytes | 0 bytes/s, done.
- Total 3 (delta 1), reused 0 (delta 0)
- To d:/jackygit2/../remote-jackygit.git
- c0449de..15a6406 master -> master
切换到jackygit仓库，同样修改jackydata01，提交修改并推送到远程仓库。这时候就出错了，提示有人改过这个文件了。推送不成功。
- #切换到jackygit
- $ cd ../jackygit
- #修改jackygit/Jackydata01
- $ echo "It's modified in jackygit" >jackydata01
- #提交jackygit的修改
- $ git commit -a -m "jackygit modify"
- [master 9ab7206] jackygit modify
- 1 file changed, 1 insertion(+), 1 deletion(-)
- 推送到远程仓库testremote，这个仓库和上面的origin是同一个远程仓库
- $ git push testremote
- To ../remote-jackygit.git
- ! [rejected] master -> master (fetch first)
- error: failed to push some refs to '../remote-jackygit.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 pull testremote master
- From ../remote-jackygit
- * branch master -> FETCH_HEAD
- Auto-merging Jackydata01
- CONFLICT (content): Merge conflict in Jackydata01
- Automatic merge failed; fix conflicts and then commit the result.
冲突用<<<<<< ====== >>>>>>隔开冲突代码，上面的是当前修改内容，下面的则是别人修改的内容。
- #输出当前jackydata01内容
- $ cat jackydata01
- <<<<<<< HEAD
- It's modified in jackygit
- =======
- It's modified in jackygit2
- >>>>>>> 15a6406ed7f889bab7e812f9e6bedb6e78431232
修改冲突内容，重新提交，推送。
- #修改Jackydata01产生的冲突
- $ echo "there is no conflict now" > jackydata01
- #提交修改冲突后文件
- $ git commit -a -m "there is no confilct now"
- [master ac2846f] there is no confilct now
- #推送到远程仓库testremote
- $ git push testremote
- Counting objects: 10, done.
- Delta compression using up to 2 threads.
- Compressing objects: 100% (4/4), done.
- Writing objects: 100% (6/6), 567 bytes | 0 bytes/s, done.
- Total 6 (delta 2), reused 0 (delta 0)
- To ../remote-jackygit.git
- 15a6406..ac2846f master -> master
2.分支合并冲突
这种情况和多人协作冲突处理办法是相似的。在这里也模拟一下。
（1）创建分支并修改内容
- #创建并跳转到分支br
- $ git checkout -b br
- Switched to a new branch 'br'
- #修改br分支中的Jackydata01
- $ echo "It's modified in br" > jackydata01
- #提交br分支中的修改
- $ git commit -a -m "br modify"
- [br 32c8755] br modify
- 1 file changed, 1 insertion(+), 1 deletion(-)
- #跳转到master分支
- $ git checkout master
- Switched to branch 'master'
- #修改master分支中的jackydata01
- $ echo "It's modified in master" > jackydata01
- #提交master分支中的修改
- $ git commit -a -m "master modify"
- [master ed84e67] master modify
- 1 file changed, 1 insertion(+), 1 deletion(-)
- #合并br到主分支上
- $ git merge br
- Auto-merging Jackydata01
- CONFLICT (content): Merge conflict in Jackydata01
- Automatic merge failed; fix conflicts and then commit the result.
- #显示br中Jackydata01内容
- $ cat jackydata01
- <<<<<<< HEAD
- It's modified in master
- =======
- It's modified in br
- >>>>>>> br
- 修改Jackydata01产生的冲突
- $ echo "It's no conflict now" > jackydata01
- #提交修改冲突后文件
- $ git commit -a -m "It's no conflict now"
- [master eb073a6] It's no conflict now
- #删除br分支
- $ git branch -d br
- Deleted branch br (was 32c8755).
Bug分支与多人协作
bug分支：
在开发中，会经常碰到bug问题，那么有了bug就需要修复，在Git中，分支是很强大的，每个bug都可以通过一个临时分支来修复，修复完成后，合并分支，然后将临时的分支删除掉。
比如我在开发中接到一个404 bug时候，我们可以创建一个404分支来修复它，但是，当前的dev分支上的工作还没有提交。比如如下：
并不是我不想提交，而是工作进行到一半时候，我们还无法提交，比如我这个分支bug要2天完成，但是我issue-404 bug需要5个小时内完成。怎么办呢？还好，Git还提供了一个stash功能，可以把当前工作现场 ”隐藏起来”，等以后恢复现场后继续工作。如下：
所以现在我可以通过创建issue-404分支来修复bug了。
首先我们要确定在那个分支上修复bug，比如我现在是在主分支master上来修复的，现在我要在master分支上创建一个临时分支，演示如下：
修复完成后，切换到master分支上，并完成合并，最后删除issue-404分支。演示如下：
现在，我们回到dev分支上干活了。
工作区是干净的，那么我们工作现场去哪里呢？我们可以使用命令 git stash list来查看下。如下：
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，可以使用如下2个方法：
- git stash apply恢复，恢复后，stash内容并不删除，你需要使用命令git stash drop来删除。
- 另一种方式是使用git stash pop,恢复的同时把stash内容也删除了。
演示如下
多人协作。
当你从远程库克隆时候，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且远程库的默认名称是origin。
- 要查看远程库的信息 使用 git remote
- 要查看远程库的详细信息 使用 git remote –v
如下演示：
一：推送分支：
推送分支就是把该分支上所有本地提交到远程库中，推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
使用命令 git push origin master
比如我现在的github上的readme.txt代码如下：
本地的readme.txt代码如下：
现在我想把本地更新的readme.txt代码推送到远程库中，使用命令如下：
我们可以看到如上，推送成功，我们可以继续来截图github上的readme.txt内容 如下：
可以看到 推送成功了，如果我们现在要推送到其他分支，比如dev分支上，我们还是那个命令 git push origin dev
那么一般情况下，那些分支要推送呢？
- master分支是主分支，因此要时刻与远程同步。
- 一些修复bug分支不需要推送到远程去，可以先合并到主分支上，然后把主分支master推送到远程去。
二：抓取分支：
多人协作时，大家都会往master分支上推送各自的修改。现在我们可以模拟另外一个同事，可以在另一台电脑上（注意要把SSH key添加到github上）或者同一台电脑上另外一个目录克隆，新建一个目录名字叫testgit2
但是我首先要把dev分支也要推送到远程去，如下
接着进入testgit2目录，进行克隆远程的库到本地来，如下：
现在目录下生成有如下所示：
现在我们的小伙伴要在dev分支上做开发，就必须把远程的origin的dev分支到本地来，于是可以使用命令创建本地dev分支：git checkout –b dev origin/dev
现在小伙伴们就可以在dev分支上做开发了，开发完成后把dev分支推送到远程库时。
如下：
小伙伴们已经向origin/dev分支上推送了提交，而我在我的目录文件下也对同样的文件同个地方作了修改，也试图推送到远程库时，如下：
由上面可知：推送失败，因为我的小伙伴最新提交的和我试图推送的有冲突，解决的办法也很简单，上面已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后在本地合并，解决冲突，再推送。
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：如下：
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的 解决冲突完全一样。解决后，提交，再push：
我们可以先来看看readme.txt内容了。
现在手动已经解决完了，我接在需要再提交，再push到远程库里面去。如下所示：
因此：多人协作工作模式一般是这样的：
- 首先，可以试图用git push origin branch-name推送自己的修改.
- 如果推送失败，则因为远程分支比你的本地更新早，需要先用git pull试图合并。
- 如果合并有冲突，则需要解决冲突，并在本地提交。再用git push origin branch-name推送。
Git常用命令总结
mkdir： XX (创建一个空目录 XX指目录名)
pwd： 显示当前目录的路径。
git init 把当前的目录变成可以管理的git仓库，生成隐藏.git文件。
git add XX 把xx文件添加到暂存区去。
git commit –m “XX” 提交文件 –m 后面的是注释。
git status 查看仓库状态
git diff XX 查看XX文件修改了那些内容
git log 查看历史记录
git reset --hard HEAD^ 或者 git reset --hard HEAD~ 回退到上一个版本
(如果想回退到100个版本，使用git reset –hard HEAD~100 )
cat XX 查看XX文件内容
git reflog 查看历史记录的版本号id
git checkout -- XX 把XX文件在工作区的修改全部撤销。
git rm XX 删除XX文件
git remote add origin https://github.com/jayfeihe/gittest1.git 关联一个远程库
git push –u(第一次要用-u 以后不需要) origin master 把当前master分支推送到远程库
git clone https://github.com/jayfeihe/gittest1.git 从远程库中克隆
git checkout –b dev 创建dev分支 并切换到dev分支上
git branch 查看当前所有的分支
git checkout master 切换回master分支
git merge dev 在当前的分支上合并dev分支
git branch –d dev 删除dev分支
git branch name 创建分支
git stash 把当前的工作隐藏起来 等以后恢复现场后继续工作
git stash list 查看所有被隐藏的文件列表
git stash apply 恢复被隐藏的文件，但是内容不删除
git stash drop 删除文件
git stash pop 恢复文件的同时 也删除文件
git remote 查看远程库的信息
git remote –v 查看远程库的详细信息
git push origin master Git会把master分支推送到远程库对应的远程分支上
Git中的Merge与Rebase操作
参考：http://www.cnblogs.com/itech/p/5188932.html
概述
你要知道的第一件事是，git rebase 和git merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支，只不过方式有些不同。
想象一下，你刚创建了一个专门的分支开发新功能，然后团队中另一个成员在master分支上添加了新的提交。这就会造成提交历史被Fork一份，用Git来协作的开发者应该都很清楚。
现在，如果master中新的提交和你的工作是相关的。为了将新的提交并入你的分支，你有两个选择：merge或rebase。
Merge
将master分支合并到feature分支最简单的办法就是用下面这些命令：
git checkout feature
git merge master
或者，你也可以把它们压缩在一行里。
git merge master feature
feature分支中新的合并提交(merge commit)将两个分支的历史连在了一起。你会得到下面这样的分支结构：
Merge好在它是一个安全的操作。现有的分支不会被更改，避免了rebase潜在的缺点（后面会说）。
另一方面，这同样意味着每次合并上游更改时feature分支都会引入一个外来的合并提交。如果master非常活跃的话，这或多或少会污染你的分支历史。虽然高级的git log 选项可以减轻这个问题，但对于开发者来说，还是会增加理解项目历史的难度。
Rebase
作为merge的替代选择，你可以像下面这样将feature分支并入master分支：
git checkout feature
git rebase master
它会把整个feature分支移动到master分支的后面，有效地把所有master分支上新的提交并入过来。但是，rebase为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。
rebase最大的好处是你的项目历史会非常整洁。首先，它不像git merge 那样引入不必要的合并提交。其次，如上图所示，rebase导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的Fork。这让你更容易使用git log 、git bisect 和gitk 来查看项目历史。
不过，这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了Rebase黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。此外，rebase不会有合并提交中附带的信息——你看不到feature分支中并入了上游的哪些更改。
交互式的rebase
交互式的rebase允许你更改并入新分支的提交。这比自动的rebase更加强大，因为它提供了对分支上提交历史完整的控制。一般来说，这被用于将feature分支并入master分支之前，清理混乱的历史。
把-i 传入git rebase 选项来开始一个交互式的rebase过程：
git checkout feature
git rebase -i master
它会打开一个文本编辑器，显示所有将被移动的提交：
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
这个列表定义了rebase将被执行后分支会是什么样的。更改pick 命令或者重新排序，这个分支的历史就能如你所愿了。比如说，如果第二个提交修复了第一个提交中的小问题，你可以用fixup 命令把它们合到一个提交中：
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
保存后关闭文件，Git会根据你的指令来执行rebase，项目历史看上去会是这样：
忽略不重要的提交会让你的feature分支的历史更清晰易读。这是git merge 做不到的。
Rebase的黄金法则
当你理解rebase是什么的时候，最重要的就是什么时候 不能 用rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。
比如说，如果你把master分支rebase到你的feature分支上会发生什么：
这次rebase将master分支上的所有提交都移到了feature分支后面。问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的master上工作。因为rebase引起了新的提交，Git会认为你的master分支和其他人的master已经分叉了。
同步两个master分支的唯一办法是把它们merge到一起，导致一个额外的合并提交和两堆包含同样更改的提交。不用说，这会让人非常困惑。
所以，在你运行git rebase 之前，一定要问问你自己“有没有别人正在这个分支上工作？”。如果答案是肯定的，那么把你的爪子放回去，重新找到一个无害的方式（如git revert）来提交你的更改。不然的话，你可以随心所欲地重写历史。
强制推送
如果你想把rebase之后的master分支推送到远程仓库，Git会阻止你这么做，因为两个分支包含冲突。但你可以传入--force 标记来强行推送。就像下面一样：
# 小心使用这个命令！
git push --force
它会重写远程的master分支来匹配你仓库中rebase之后的master分支，对于团队中其他成员来说这看上去很诡异。所以，务必小心这个命令，只有当你知道你在做什么的时候再使用。
仅有的几个强制推送的使用场景之一是，当你在想向远程仓库推送了一个私有分支之后，执行了一个本地的清理（比如说为了回滚）。这就像是在说“哦，其实我并不想推送之前那个feature分支的。用我现在的版本替换掉吧。”同样，你要注意没有别人正在这个feature分支上工作。
工作流
rebase可以或多或少应用在你们团队的Git工作流中。在这一节中，我们来看看在feature分支开发的各个阶段中，rebase有哪些好处。
第一步是在任何和git rebase 有关的工作流中为每一个feature专门创建一个分支。它会给你带来安全使用rebase的分支结构：
本地清理
在你工作流中使用rebase最好的用法之一就是清理本地正在开发的分支。隔一段时间执行一次交互式rebase，你可以保证你feature分支中的每一个提交都是专注和有意义的。你在写代码时不用担心造成孤立的提交——因为你后面一定能修复。
调用git rebase 的时候，你有两个基(base)可以选择：上游分支（比如master）或者你feature分支中早先的一个提交。我们在“交互式rebase”一节看到了第一种的例子。后一种在当你只需要修改最新几次提交时也很有用。比如说，下面的命令对最新的3次提交进行了交互式rebase：
git checkout feature
git rebase -i HEAD~3
通过指定HEAD~3作为新的基提交，你实际上没有移动分支——你只是将之后的3次提交重写了。注意它不会把上游分支的更改并入到feature分支中。
如果你想用这个方法重写整个feature分支，git merge-base 命令非常方便地找出feature分支开始分叉的基。下面这段命令返回基提交的ID，你可以接下来将它传给git rebase：
git merge-base feature master
交互式rebase是在你工作流中引入git rebase 的的好办法，因为它只影响本地分支。其他开发者只能看到你已经完成的结果，那就是一个非常整洁、易于追踪的分支历史。
但同样的，这只能用在私有分支上。如果你在同一个feature分支和其他开发者合作的话，这个分支是公开的，你不能重写这个历史。
用带有交互式的rebase清理本地提交，这是无法用git merge 命令代替的。
将上游分支上的更改并入feature分支
在概览一节，我们看到了feature分支如何通过git merge 或git rebase 来并入上游分支。merge是保留你完整历史的安全选择，rebase将你的feature分支移动到master分支后面，创建一个线性的历史。
git rebase 的用法和本地清理非常类似（而且可以同时使用），但之间并入了master上的上游更改。
记住，rebase到远程分支而不是master也是完全合法的。当你和另一个开发者在同一个feature分之上协作的时候，你会用到这个用法，将他们的更改并入你的项目。
比如说，如果你和另一个开发者——John——往feature分支上添加了几个提交，在从John的仓库中fetch之后，你的仓库可能会像下面这样：
就和并入master上的上游更改一样，你可以这样解决这个Fork：要么merge你的本地分支和John的分支，要不把你的本地分支rebase到John的分支后面。
注意，这里的rebase没有违反Rebase黄金法则，因为只有你的本地分支上的commit被移动了，之前的所有东西都没有变。这就像是在说“把我的改动加到John的后面去”。在大多数情况下，这比通过合并提交来同步远程分支更符合直觉。
默认情况下，git pull 命令会执行一次merge，但你可以传入--rebase 来强制它通过rebase来整合远程分支。
用Pull Request进行审查
如果你将pull request作为你代码审查过程中的一环，你需要避免在创建pull request之后使用git rebase。只要你发起了pull request，其他开发者能看到你的代码，也就是说这个分支变成了公共分支。重写历史会造成Git和你的同事难以找到这个分支接下来的任何提交。
来自其他开发者的任何更改都应该用git merge 而不是git rebase 来并入。
因此，在提交pull request前用交互式的rebase进行代码清理通常是一个好的做法。
并入通过的功能分支
如果某个功能被你们团队通过了，你可以选择将这个分支rebase到master分支之后，或是使用git merge 来将这个功能并入主代码库中。
这和将上游改动并入feature分支很相似，但是你不可以在master分支重写提交，你最后需要用git merge 来并入这个feature。但是，在merge之前执行一次rebase，你可以确保merge是一直向前的，最后生成的是一个完全线性的提交历史。这样你还可以加入pull request之后的提交。
如果你还没有完全熟悉git rebase，你还可以在一个临时分支中执行rebase。这样的话，如果你意外地弄乱了你feature分支的历史，你还可以查看原来的分支然后重试。
比如说：
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [清理目录]
git checkout master
git merge temporary-branch
总结
你使用rebase之前需要知道的知识点都在这了。如果你想要一个干净的、线性的提交历史，没有不必要的合并提交，你应该使用git rebase 而不是git merge 来并入其他分支上的更改。
另一方面，如果你想要保存项目完整的历史，并且避免重写公共分支上的commit， 你可以使用git merge。两种选项都很好用，但至少你现在多了git rebase这个选择。