Git总结

• 集中式与分布式
  
  Git属于分布式版本控制系统，而SVN属于集中式.

两者区别

1. 集中式版本控制只有中心服务器拥有一份代码，而分布式版本控制每个人的电脑上就有一份完整的代码
2. 集中式版本控制有安全性问题，当中心服务器挂了所有人都没办法工作
3. 集中式版本控制需要联网才能工作，如果网速过慢，那么提交一个文件会慢的让人无法忍受。分布式版本控制不需要联网就能工作
4. 分布式版本控制新建分支、合并分支操作速度非常快，而集中式版本控制新建一个分支相当于复制一份完整代码

• 中心服务器

中心服务器用来交换每个用户的修改，没有中心服务器也能工作，但是中心服务器能够24小时保持开机状态，这样就能更方便地交换修改。


Github就是一个中心服务器

• 工作流

新建一个仓库之后，当前目录就成为了工作区，工作区下有一个隐藏目录.git,它属于Git的版本库.


Git的版本库有一个称为Stage的暂存区以及最后的History版本库，History存储所有分支信息，使用一个HEAD指针指向当前分支.

git add files 把文件的修改添加到暂存区
git commit -m 'XX'把暂存区的修改提交到当前分支，提交之后暂存区就被清空了
git reset -- files 使用当前分支上的修改覆盖暂存区，用来撤销最后一次 git add files
git checkout -- files 使用暂存区的修改覆盖工作目录，用来撤销本地修改

可以跳过暂存区域直接从分支中取出修改，或者直接提交修改到分支中。

git commit -a 直接把所有文件的修改添加到暂存区然后执行提交
git checkout HEAD -- files 取出最后一次修改，可以用来进行回滚操作

• 版本回退

每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

git log 显示从最近到最远的提交日志  $ git log --pretty=oneline可以减少输出信息
注意：在Git中，用HEAD表示当前版本上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100
git log --graph 可以查看分支合并图
git reset --hard HEAD^回退到上一版本
git reset --hard 版本号（某几位）#git会自动去找完整的版本号

• 删除文件

git rm files #删除指定文件
git commit -m 'XX'

• 分支实现

使用指针将每个提交连接连成一条时间线，HEAD指针指向当前分支指针

新建分支是新建一个指针指向时间线的最后一个节点，并让HEAD指针指向新分支，表示新分支成为当前分支

每次提交只会让当前分支指针向前移动，而其他分支指针不会移动

合并分支也只需要改变指针即可

git checkout -b dev#创建dev分支，并且切换到了dev分支 == git branch dev(创建) +  git checkout dev(切换)
git branch #查看当前分支
git checkout XXX #切换到指定分支
git merge dev #把dev分支的工作成果合并到master分支上
git branch -d dev #删除dev分支

• 冲突

当两个分支都对同一个文件的进行了修改，在分支合并时就会产生冲突

Git会使用 <<<<<<< ，======= ，>>>>>>> 标记出不同分支的内容，只需要把不同分支中冲突部分修改成一样就能解决冲突。

<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

修改对应文件的内容 再add commit 操作 并删除分支

• Fast Forward

“快进式合并”（fast-farward merge），会直接将 master 分支指向合并的分支，这种模式下进行分支合并会丢失分支信息，也就不能在分支历史上看出分支信息。

可以在合并时加上 --no-ff 参数来禁用 Fast forward 模式，并且加上 -m 参数让合并时产生一个新的 commit。

$ git merge --no-ff -m "merge with no-ff" dev

• 分支管理策略

master 分支应该是非常稳定的，只用来发布新版本；

日常开发在开发分支 dev 上进行。

• 储藏

在一个分支上操作之后，如果还没有将修改提交到分支上，此时进行切换分支，那么另一个分支上也能看到新的修改。这是因为所有分支都共用一个工作区的缘故。

可以使用 git stash 将当前分支的修改储藏起来，此时当前工作区的所有修改都会被存到栈中，也就是说当前工作区是干净的，没有任何未提交的修改。此时就可以安全的切换到其它分支上了。

git stash #可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作： 即git status看不到任何修改内容无提示
Saved working directory and index state \ "WIP on master: 049d078 added the index file"
git stash list #查看储藏内容
git stash apply #回复储藏内容 但是不会删除
git stash drop #用来删除
git stash pop，#恢复的同时把stash内容也删了：

该功能可以用于 bug 分支的实现。如果当前正在 dev 分支上进行开发，但是此时 master 上有个 bug 需要修复，但是 dev 分支上的开发还未完成，不想立即提交。在新建 bug 分支并切换到 bug 分支之前就需要使用 git stash 将 dev 分支的未提交修改储藏起来。

• 多人协作

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

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

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2。如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
*如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，
使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
再用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。*建立本地分支和远程分支的关联
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

• .gitignore文件

忽略以下文件：

操作系统自动生成的文件，比如缩略图；
编译生成的中间文件，比如 Java 编译产生的 .class 文件；
自己的敏感信息，比如存放口令的配置文件。