git----常见使用速查命令及git原理

0.常用命令1

1.git中brunch的使用和理解一定理解brunch的指针理解和分叉

分支创建

Git 是怎么创建新分支的呢? 很简单,它只是为你创建了一个可以移动的新的指针。 比如,创建一个 testing 分支, 你需要使用 git branch 命令:

$ git branch testing

这会在当前所在的提交对象上创建一个指针。

那么,Git 又是怎么知道当前在哪一个分支上呢? 也很简单,它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统(如 Subversion 或 CVS)里的 HEAD 概念完全不同。 在 Git 中,它是一个指针,指向当前所在的本地分支(译注:将 HEAD 想象为当前分支的别名)。 在本例中,你仍然在 master 分支上。 因为 git branch 命令仅仅 创建 一个新分支,并不会自动切换到新分支中去。

你可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate

$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project

正如你所见,当前 “master” 和 “testing” 分支均指向校验和以 f30ab 开头的提交对象。

分支切换

要切换到一个已存在的分支,你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去:

$ git checkout testing

这样 HEAD 就指向 testing 分支了。

那么,这样的实现方式会给我们带来什么好处呢? 现在不妨再提交一次:

$ vim test.rb
$ git commit -a -m 'made a change'

如图所示,你的 testing 分支向前移动了,但是 master 分支却没有,它仍然指向运行 git checkout 时所指的对象。 这就有意思了,现在我们切换回 master 分支看看:

$ git checkout master

这条命令做了两件事。 一是使 HEAD 指回 master 分支,二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说,你现在做修改的话,项目将始于一个较旧的版本。 本质上来讲,这就是忽略 testing分支所做的修改,以便于向另一个方向进行开发。

Note
分支切换会改变你工作目录中的文件

在切换分支时,一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支,你的工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务,它将禁止切换分支。

我们不妨再稍微做些修改并提交:

$ vim test.rb
$ git commit -a -m 'made other changes'

现在,这个项目的提交历史已经产生了分叉(参见 项目分叉历史)。 因为刚才你创建了一个新分支,并切换过去进行了一些工作,随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支:你可以在不同分支间不断地来回切换和工作,并在时机成熟时将它们合并起来。 而所有这些工作,你需要的命令只有 branchcheckout 和 commit

你可以简单地使用 git log 命令查看分叉历史。 运行 git log --oneline --decorate --graph --all ,它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件,所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符),如此的简单能不快吗?

这与过去大多数版本控制系统形成了鲜明的对比,它们在创建分支时,将所有的项目文件都复制一遍,并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟,有时甚至需要好几分钟。所需时间的长短,完全取决于项目的规模。而在 Git 中,任何规模的项目都能在瞬间创建新分支。 同时,由于每次提交都会记录父对象,所以寻找恰当的合并基础(译注:即共同祖先)也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

 分支合并

git merge --no-ff -m "合并的信息" 分支
#这种合并方式是普通合并,会将合并当做一次commit,否则的话使用快速合并,没有合并这一操作的提交,log很难看

合并之后两个分支起点全都变化了

2.使用分支的情况,以及合并分支的两种不同情况及其操作带来的问题

2.1实际上当你开发一个新功能时,或者修改一个bug时,为了不影响已经发布的软件版本,你可以创建一个新分支,以此来保证master分支的完整性。但要注意合并分支时候的两种情况

master是当前发布版本的分支,iss53是你正在开发的新功能的分支(未发布),hotfix是你正在修改发布版本中bug的分支,第一种合并分支情况,将hotfix分支合并回去,此时不存在冲突,master后退一下就可以了。合并后的情况如下

当你开发好iss53功能后在合并分支就发生了不同的情况,也就是第二种情况,C3跟C4可能发生了冲突,这时候就要解决冲突了

 3.git撤销本地修改与回退版本

1. 使用 git checkout 撤销本地修改

即放弃对本地已修改但尚未提交的文件的修改,还原其到未修改前的状态。
注意: 已 add/ commit 的文件不适用个方法,应该用本文提到的第二种方法。

命令如下:

1 git checkout . # 撤销对所有已修改但未提交的文件的修改,但不包括新增的文件
2 git checkout [filename] # 撤销对指定文件的修改,[filename]为文件名

2. 使用 git reset 回退项目版本

可以回退到任意已经提交过的版本。已 add / commit 但未 push 的文件也适用。

命令如下:

1 git reset --hard [commit-hashcode] 
2 # [commit-hashcode]是某个 commit 的哈希值,可以用 git log 查看

更复杂的版本回复可以百度,总之总有后悔药可以吃,

本小节摘自https://blog.csdn.net/dandelion_drq/article/details/51259831

4.查看日志

4.1 git log即可查看本地提交日志,git log <remote>也就是git remote origin可以查看远程的提交历史

4.2 git log还可以加参数 有很多好用的参数比如 git log commitid  或者 git log filename  git log -p等等等等

4.2 remote可以看成远程仓库的指针类型,而origin则是这个类型下具体的一个值,他指向你clone的位置,其实就是 int a;中二者的关系。操作整体远程仓库时候用remote(比如远程仓库有几个,版本,url)、具体到哪一个时候用origin(比如指定哪个远程仓库的哪个分支)

5.先在本地git init创建仓库后,然后git remote add origin url后,如何将本地的分支追踪到远程分支

# 第一次提交的时候
git push -u origin master

 

posted @ 2018-11-05 23:34  回溯法  阅读(361)  评论(0编辑  收藏  举报