标签：两种 指针 git 控制系统 远程同步 sla 个人 image 新版
linux之父Linus为了更好的管理他自己的开源项目linux系统而自己开发了一个软件，这个软件可以帮助Linux更好的进行开源开发，名字就叫Git。
它是个分布式版本控制系统，Git是最当前流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。
sudo apt-get install gi./config
make
sudo make install什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”
创建完版本库，当前路径里就会发现一个.git的文件夹，这个就是Git的版本库。Git版本库里面有一个称为stage（或者叫index）的暂存区，和还有Git为我们自动创建的第一个分支master，以及指向master的第一个指针HEAD，示意图如下：
$ git status
On branch master
nothing to commit, working tree clean$ git remote add origin git@github.com:slaming/learngit.git添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
$ git push -u origin master如果远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
创建新的分支：
$ git branch dev切换到dev分支：
$ git checkout dev为了简单，常用下面命令，创建新的分支dev，并且切换到dev分支：
$ git checkout -b dev查看版本库有什么分支，git branch命令会列出所有分支，当前分支前面会标一个*号：
$ git branch
* dev
master合并分支：
$ git merge dev每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点,每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是切换到master分支，直接把master指向dev的当前提交，这样就完成了合并：
假如开辟了新的分支features1
$ git checkout -b feature1修改readme.txt最后一行，改为：
Creating a new branch is quick AND simple.提交：
$ git add readme.txt
$ git commit -m "AND simple"切换到master分支：
$ git checkout master在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.提交：
$ git add readme.txt
$ git commit -m "& simple"
合并：
$ git merge feature1这时Git不能自动合并，会出现冲突。
三路合并就是先找出一个基准，然后以基准为Base 进行合并，如果2个文件相对基准(base)都发生了改变 那git 就报冲突，然后让你人工决断。否则，git将取相对于基准(base)变化的那个为最终结果。
Base 代表上一个版本，即公共祖先
Mine 代表你本地修改
Theirs 代表其他人修改
这样当git进行合并的时候，git就知道是其他人修改了，本地没有更改，git就会自动把最终结果变成如下，这个结构也是大多merge 工具的常见布局。
如果换成下面的这样，就需要人工解决了：
上面就是git merge 最基本的原理 “三路合并”。
上面①~⑨代表一个个修改集合(commit)每个commit都有一个唯一7位SHA-1唯一表示。
①，②，④，⑦修改集串联起来就是一个链，此时用master指向这个集合就代表master分支，分支本质是一个快照，其实类比C中指针
同样dev分支也是由一个个commit组成
现在在dev分支上由于各种原因要运行git merge master需要把master分支的更新合并到dev分支上，本质上就是合并修改集 ⑦(Mine) 和 ⑧(Theirs) ，此时我们要 利用DAG(有向无环图)相关算法找到我们公共的祖先 ②（Base）然后进行三方合并，最后合并生成 ⑨。
你从远程仓库克隆到本地，就可以开始你的开发了。
要查看远程库的信息，用git remote：
$ git remote
origin或者，用git remote -v显示更详细的信息：
$ git remote -v
origin git@github.com：slaming/learngit.git (fetch)
origin git@github.com:slaming/learngit.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
把分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin dev但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
多人协作时，大家都会往master和dev分支上推送各自的修改。
当你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的地方作了修改，并试图推送：
$ git push origin dev推送会失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，和merge类似。这时需要手动改写。
标签：两种 指针 git 控制系统 远程同步 sla 个人 image 新版
原文地址：https://www.cnblogs.com/npulzb/p/11966831.html
