1、Git Commits
Git 仓库的一次commit记录所提交目录下所有文件的快照,感觉像是大量的复制和粘贴,但Git并非如此!
Git 希望提交的记录尽可能的轻量,所以每次进行提交时,它不会简单地复制整个目录,条件允许的情况下,Git会把提交压缩成从代码仓库中的一个版本到下一个版本的变化合集,也叫作“增量delta”。
Git还维护了“提交的创建时间”的历史记录,因此大部分提交都有祖先,一般在图形解释中会使用箭头来表示这种关系,对于项目组成员来说,这份提交历史对大家都有好处。
Git提交记录十分轻量并且可以快速切换!
2、 Git Branches
Git的分支同样十分轻量,他们只是简单地指向某个提交记录而已——仅此而已。所以许多Git爱好者会念叨:早点建分支!经常建分支!
创建分支没有存储或者内存上的开销,所以按
逻辑分解工作比维护但已的代码树要简单。
使用分支其实就是在说:我想包含本次提交及所有的父提交记录。
3、Git checkout
切换分支,实际上是将HEAD指向不同的提交。当前:HEAD->master->hashcode1;使用命令 “git checkout bugFix” 后,HEAD->bugFix->hashcode2;4、Git Merging
我们可以通过Git branch 新建一个分支,在其上开发新功能,然后合并分支,回到主线。
Git merge 是第一个实现合并的方法。合并产生一个特殊的提交记录,它包含两个唯一父提交。有两个父提交的提交记录本质上是:“我想把这两个父提交本身以及它们的父提交集合都包含进来”
5、Git Rebase
Rebasing 是在分支之间合并的第二个方法。Rebasing 就是取出一系列的提交记录,“复制”它们,然后把它们放在别的地方放下来。
虽然听上去难以理解,rebasing的优势是可以常遭更加线性的提交历史。假如只允许使用rebasing。代码库的提交日志/历史会更好看。
6、HEAD
HEAD 是当前提交记录的符号名称——其实就是你正在其基础上进行工作的提交记录。
HEAD总是指向最近的一次提交记录,表现为当前工作树。大多数修改工作树的Git命令都开始于改变HEAD指向。
HEAD通常指向分支名(比如 bugFix)。你提交(commit)时,改变了bugFix的状态,这一变化则通过HEAD变得可见。
指向为:HEAD->bugFix->hashcode(当前分支的hash值)
7、使用^和^<num>在Git中相对移动
通过将HEAD指向hashcode的方法,由于hashcode比较长,用起来不方便。可以通过相对引用来实现。
- 使用^向上移动1个提交记录: git checkout master^
- 使用~<num>向上移动多个提交记录: git checkout HEAD~3
8、使用-f选项直接上分支指向另一个提交
git branch -f master HEAD~3
强制移动master指向HEAD的第三级父提交。
9、Git reset和Git revert
使用git reset 实现将本地的分支记录回退到上一个提交记录来实现撤销改动,可以认为这是在“重写历史”,原来指向的提交记录好像从来没有提交过一样。
如果需要撤销更改并传播给别人,则需要使用git revert。使用git revert实际上是在当前提交上新建一个提交记录与当前提交记录的父提交相同。
以上,能够实现开发者的主要需求,然后,剩余的10% 可能在处理复杂的工作流时,非常重要。
10、Git cherry-pick、git tag
git cherry-pick用于实现抓取其余分支下的提交到当前分支;git tag 用于实现给一些里程碑式的提交打标;
更加高级具体的练习教程请访问:learngitbranching.js.org