Git Commit
Git 仓库中的提交记录保存的是你的目录下所有文件的快照,就像是把整个目录复制,然后再粘贴一样,但比复制粘贴优雅许多!
Git 希望提交记录尽可能地轻量,因此在你每次进行提交时,它并不会盲目地复制整个目录。条件允许的情况下,它会将当前版本与仓库中的上一个版本进行对比,并把所有的差异打包到一起作为一个提交记录。
Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说,维护提交历史对大家都有好处。
git commit
Git Branch
Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂:
#早建分支!多用分支!#
这是因为即使创建再多分的支也不会造成储存或内存上的开销,并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。
'git branch <分支名>' 来创建分支
‘git checkout <分支名>' 来切换分支
'git checkout -b <分支名>' 创建并切换分支
将两个分支合并到一起。就是说我们新建一个分支,在其上开发某个新功能,开发完成后再合并回主线。
1、git merge
在 Git 中合并两个分支时会产生一个特殊的提交记录,它有两个父节点。翻译成自然语言相当于:“我要把这两个父节点本身及它们所有的祖先都包含进来。”
我们准备了两个分支,每个分支上各有一个独有的提交。这意味着没有一个分支包含了我们修改的所有内容。咱们通过合并这两个分支来解决这个问题。
我们要把 bugFix
合并到 master
里
运行命令git marge bugFix
首先,master
现在指向了一个拥有两个父节点的提交记录。假如从 master
开始沿着箭头向上看,在到达起点的路上会经过所有的提交记录。这意味着 master
包含了对代码库的所有修改。
2、Git Rebase
第二种合并分支的方法是 git rebase
。Rebase 实际上就是取出一系列的提交记录,“复制”它们,然后在另外一个地方逐个的放下去。
Rebase 的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用 Rebase 的话,代码库的提交历史将会变得异常清晰。
git rebase master
//讲当前分支复制一份放在master之下
git rebase <节点名>
与 git merge <节点名>
的相同之处
此时运行git rebase <节点名>
或 git merge <节点名>
都会达到相同的效果,将父节点的标签名移向子节点。
运行结果如图,虽然我也不知道有什么用吧,先记录一下。