git clone <版本库的网址> <本地目录名></本地目录名></版本库的网址>
 
git log                    // 查看看commit历史记录

git add & git commit       //提交当前工作空间的修改内容到索引库中



git revert  version        //还原一个版本的修改，必须提供一个具体的Git版本号 version
git tag version            //可以将某个具体的版本打上一个标签这样你就不需要记忆复杂的版本号哈希值了



git branch                 //查看当前分支
git brance -a              //查看所有分支
git branch test            //就新建了一个名字叫 test 的分支

git checkout -b test      //这个命令的意思就是新建一个test分支，并且自动切换到test分支
git checkout test         //切换到test分支


git branch -d   test     //把test分支删除了。
git branch -D  test     //强制删除test分支

 

git push --force origin

//如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做git pull合并差异，然后再推送
到远程主机。这时，如果你一定要推送，可以使用–force选项。上面命令使用–force选项，结果导致远程主机
上更新的版本被覆盖。除非你很确定要这样做，否则应该尽量避免使用–force选项。

git fetch //相当于是从远程获取最新版本到本地，不会自动merge（更新remote索引，获取远程服务器的最新分支）

 
git pull  //相当于是从远程获取最新版本到本地，会自动merge

git push origin :a //删除远程分支

对应语法为：git push [远程库名] [本地分支]:[远程分支]
即向待删除远程分支推送一个空的本地分支。



git stash          //备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次
提交的内容一致。同时，将当前的工作区内容保存到Git栈中。



git stash pop    //从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash
的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。


rebase的效果
假设现在有两个分支 A B 1. 在B分支上执行 git merge A 后 A就被合到B上了 2. 在B分支上执行 git 
rebase A 后，效果与merge是一样的，但是 A就没有了，两个分支就合在一起了。这两种方式的最终结果都相
同，但是合并历史却不同；



rebase的原理是
找到两个分支最近的共同祖先，根据当前分支(上例中branch1)的提交历史生成一系列补丁文件，然后以基地分支
最后一个提交为新的提交起始点，应用之前生成的补丁文件，最后形成一个新的合并提交。从而使得变基分支成为
基地分支的直接下游。rebase一般被翻译为变基


rebase的风险
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行变基操作。因为不管是git rebase <branch>
还是git rebase <commitid>,都重置了提交的SHA-1校验和，当你将本地变基后的提交推送到远端后，别人从服
务器同步代码时，由于相同的内容却有不同的SHA-1校验值，因此会再此进行一次合并，于是就会有两个作者、
commit信息完全相同的提交，但是SHA-1校验值不同，这无疑会带来麻烦。因此，如果把变基当成一种在推送之前
清理提交历史的手段，而且仅仅变基那些尚未公开的提交对象，就没问题。如果变基那些已经公开的提交对象，并
且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。