git使用笔记

有点乱,以后再详细整理,本文是按日期记得笔记。

一, GitHub新建托管项目

1要托管到github,那你就应该要有一个属于你自己的github帐号,所以你应该先到github.com注册

打开浏览器

在地址栏输入地址:github.com

填写用户名、邮箱、密码

点击Sign up即可简单地注册

完成注册,进入github平台,

2点击new repositories 新建一个新项目(你也可以加入到一个已有的项目)

3新建项目的操作,其实很简单,输入项目名就可以直接Create

4此时的界面,我想大家都应该很熟悉了。点击右边栏的剪切板图标,记录下你的项目地址。

5上传项目至GitHub

首先你要在本地计算机中安装一个git客户端。

你可以直接使用GitHub客户端,也可以用其他。

因本人使用的是msysgit,所以这里以msysgit作为介绍(msysgit同样也是目前最为广泛实用的工具之一)。

打开msysgit.github.io

下载并安装最新版本的msysgit

安装完成后,进入到要托管的项目根目录,

右键启动Git Bash命令行

如下图所示

输入git  clone  接着将先前记录下来的地址复制到后面,回车

将下载下来的项目文件夹的所有文件及文件夹,包括.git文件夹在内,全部拷贝到你的托管项目的根目录(或者将你的托管项目拷贝到该目录)

cd test

进入到该托管项目的根目录。

输入

git add .    

将改动的地方添加到版本管理器

输入

git  commit -m "changes log"  

提交到本地的版本控制库里,

引号里面是你对本次提交的说明信息。

最后输入

git push -u origin master  

将你本地的仓库提交到你的github账号里,

此时会要求你输入你的github的账号和密码。

回到你的github.com中的项目页。

里面的文件是不是已经发生改变了?

至此,

github项目已经成功更新。

更多的github的操作,你可以自己慢慢的体会。但有了这第一步认识,我相信你以后的摸索会更加容易得多。

最后push的时候有有问题,这样处理#$ unset SSH_ASKPASS

另外一种,只要知道你github的地址,可以不用在上面先创建,直接在本地操作,完了push就可以,过程如下:

touch README.rm

git init

git  add .

git commit -m 'init'

git remote add origin xxxxxx

git push -u origin master 


二,一些常用的命令

1 查看远程分支

git branch -a 

2,查看本地分支

git branch  

3创建分支

git branch test  

4把分支推到远程分支 

git push origin test  

5切换分支到test

git checkout test 

6删除本地分支   git branch -d xxxxx

7,查看提交日志git log

8,查看状态git status

先要切换到要推送的分支

git push origin local_branch:remote_branch

git push origin v1.0.0:v1.0.0

git status命令可以列出当前目录所有还没有被git管理的文件和被git管理且被修改但还未提交(git commit)的文件.

9,查看远程库git remote -v

10,添加远程库

git remote add pratice https://github.com/zhuihouyigemeng/prace.git

11,删除远程库git remote rm pratice,远程库在哪里(githug页面哪里能看到)?

12git config --global user.name "Your Name"

    $ git config --global user.email wirelessqa.me@gmail.com  

13在本地新建一个分支: git branch Branch1
切换到你的新分支: git checkout Branch1
将新分支发布在github上: git push origin Branch1
在本地删除一个分支: git branch -d Branch1
github远程端删除一个分支:git push origin :Branch1   (分支名前的冒号代表删除)

Git分支下的目录结构一样,的作用是什么?本地提交是作用是什么?本地提交和本地没提交有什么区别?Git remote add远程库是不是和本地添加一个文件夹一样?

14git remote show origin查看远程库的意思

15要新建并切换到该分支,运行git checkout 并加上 -b 参数:

$ git checkout -b iss53

16创建+切换分支:git checkout -bname 

合并某分支到当前分支:git merge name 

删除分支:git branch -d name

17,本地分支重命名git branch -m delelop develop

18,推送到git push origin develop

19,删除远程分支git push --delete origin haverest_v2.0

20  比如,如果要将开发中的分支(develop),合并到稳定分支(master),
     首先切换的master分支:git checkout master
     然后执行合并操作:git merge develop

21,设置全局变量

git config --global user.name "zuihouyigemeng"

git config --global ylyylsy@126.com

git config --global http.postBuffer 524288000

git config --global http.postBuffer 20480000

git config --list

git config core.autocrlf false

22,分支管理
创建分支很简单:git branch <分支名>
切换分支 git checkout <分支名>该语句和上一个语句可以和起来用一个语句表示:git checkout -b <分支名>
合并分支,比如,如果要将开发中的分支(develop),合并到稳定分支(master),首先切换的master分支:git checkout master。然后执行合并操作:git merge develop。如果有冲突,会提示你,调用git status查看冲突文件。这里有两种方法比较常用,git reset gitstash
分支衍合,分支衍合和分支合并的差别在于,分支衍合不会保留合并的日志,不留痕迹,而 分支合并则会保留合并的日志。要将开发中的分支(develop),衍合到稳定分支(master)。首先切换的master分支:git checkout master。然后执行衍和操作:git rebase develop
如果有冲突,会提示你,调用git status查看冲突文件。
所有冲突解决后,git rebase --continue 提交更改。
 删除分支
     执行git branch -d <分支名>
     如果该分支没有合并到主分支会报错,可以用以下命令强制删除git branch -D <分支名>

23,git remote add命令用于添加远程主机。

24,初始化git仓库git init

25.git remote add origin git@xx.xx.xx.xx:repos/xxx/xxx/xxx.git

26.git push origin 本地分支:远程分支

27git log -p                      查看日志和改动。

经试验发现,可以查看上次的修改。,

git log  

git log <file>      # 查看该文件每次提交记录  

git log -p <file>   # 查看每次详细修改内容的diff  

git log -p -2       # 查看最近两次详细修改内容的diff  

git log --stat      #查看提交统计信

28git commit -a

git commit -a这个命令可以直接提交所有修改,省去了你git addgit diffgit commit的工序,注意:无法把新增文件或文件夹加入进来,所以,如果你新增了文件或文件夹,那么就要老老实实的先git add .,再git commi

29,如何检查修改过的文件

Git clone (-b应该可以指定分支)

好像与合并有关系

git pull --rebase origin master

如何解决failed to push some refs to git

出现错误的主要原因是github中的README.md文件不在本地代码目录中

可以通过如下命令进行代码合并【注:pull=fetch+merge]

git pull --rebase origin master

30,git log -p -2 显示最近两次提交的区别,这个命令我常用GIT DIFF HEAD来代替,以后可以用LOG了,好像方便一点。

31,用 --oneline 选项来查看历史记录的简洁的版本。

git log --oneline

32,用 --graph 选项,查看历史中什么时候出现了分支、合并。以下为相同的命令,开启了拓扑图选项

git log --oneline --graph
33,逆向查看
git log --reverse --oneline



warning: LF will be replaced by CRLF

windows中的换行符为 CRLF, 而在linux下的换行符为LF,所以在执行add . 时出现提示,解决办法:

[plain] view plain copy 

$ rm -rf .git  // 删除.git  

$ git config --global core.autocrlf false  //禁用自动转换    

 

然后重新执行:

[plain] view plain copy 

$ git init    

$ git add .  

 

git config core.autocrlf false

 

解决Unable to rewind rpc post data

在使用git提交项目到服务器上时,会提示Unable to rewind rpc post datatry increasing http.postBuffer

1

2

git commit -m "commit"

git push origin

在提交的项目内容都很小时没有问题,如果文件较大,则会提交失败,提示

1

Unable to rewind rpc post data - try increasing http.postBuffer

需要将http.postBuffer设置成适合的值

1

2

git config --global http.postBuffer 20480000

git config --list

再次提交即可成功。

 

$ git add file.txt

$ git commit

注意:提交注释里已经有一些关于合并的信息了,通常是用这些默认信息,但是你可以添加一些你想要的注释。

上面这些就是你要做一个简单合并所要知道的,但是git提供更多的一些信息来 帮助解决冲突。

三、撒销一个合并

如果你觉得你合并后的状态是一团乱麻,想把当前的修改都放弃,你可以用下面的命令回到合并之前的状态:

$ git reset --hard HEAD

或者你已经把合并后的代码提交,但还是想把它们撒销:

$ git reset --hard ORIG_HEAD

但是刚才这条命令在某些情况会很危险,如果你把一个已经被另一个分支合并的分支给删了,那么以后在合并相关的分支时会出错。

关于撤销的更多内容请参考《git reset简介

四、快速向前合并

还有一种需要特殊对待的情况,在前面没有提到。通常,一个合并会产生一个合并提交(commit),把两个父分支里的每一行内容都合并进来。

但是,如果当前的分支和另一个分支没有内容上的差异,就是说当前分支的每一个提交(commit)都已经存在另一个分支里了,git就会执行一个“快速向前"(fast forward)操作;git不创建任何新的提交(commit),只是将当前分支指向合并进来的分支。

五、在合并过程中得到解决冲突的协助

git会把所有可以自动合并的修改加入到索引中去,所以git diff只会显示有冲突的部分.它使用了一种不常见的语法:

$ git diff

diff --cc file.txt

index 802992c,2b60207..0000000

--- a/file.txt

+++ b/file.txt

@@@ -1,1 -1,1 +1,5 @@@

++<<<<<<< HEAD:file.txt

 +Hello world

++=======

+ Goodbye

++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

回忆一下, 在我们解决冲突之后,得到的提交会有两个而不是一个父提交一个父提交是当前分支提交前的HEAD,;另外一个父提交是被合并分支的HEAD,被暂时存在MERGE_HEAD.

在合并过程中, 索引中保存着每个文件的三个版本.三个"文件暂存(file stage)"中的每一个都代表了文件的不同版本:

$ git show :1:file.txt  # 两个分支共同祖先中的版本.

$ git show :2:file.txt  # HEAD中的版本.

$ git show :3:file.txt  # MERGE_HEAD中的版本.

当你使用git diff去显示冲突时,它在工作树(work tree), 暂存2(stage 2)和暂存3(stage 3)之间执行三路diff操作,只显示那些两方都有的块(换句话说,当一个块的合并结果只从暂存2中得到时,是不会被显示出来的;对于暂存3来说也是一样).

上面的diff结果显示了file.txt在工作树,暂存2和暂存3中的差异git不在每行前面加上单个'+'或者'-',相反地,它使用两栏去显示差异:第一栏用于显示第一个父提交与工作目录文件拷贝的差异,第二栏用于显示第二个父提交与工作文件拷贝的差异. (参见git diff-files中的"COMBINED DIFF FORMAT"取得此格式详细信息.)

在用直观的方法解决冲突之后(但是在更新索引之前), diff输出会变成下面的样子:

$ git diff

diff --cc file.txt

index 802992c,2b60207..0000000

--- a/file.txt

+++ b/file.txt

@@@ -1,1 -1,1 +1,1 @@@

- Hello world

-Goodbye

++Goodbye world

上面的输出显示了解决冲突后的版本删除了第一个父版本提供的"Hello world"和第二个父版本提供的"Goodbye",然后加入了两个父版本中都没有的"Goodbye world".

一些特别diff选项允许你对比工作目录和三个暂存中任何一个的差异:

$ git diff -1 file.txt      # 与暂存1进行比较

$ git diff --base file.txt          # 与上相同

$ git diff -2 file.txt      # 与暂存2进行比较

$ git diff --ours file.txt          # 与上相同

$ git diff -3 file.txt      # 与暂存3进行比较

$ git diff --theirs file.txt    # 与上相同.

还有,git loggitk命令也为合并操作提供了特别的协助:

$ git log --merge

$ gitk --merge

这会显示所有那些只在HEAD或者只在MERGE_HEAD中存在的提交,还有那些更新(touch)了未合并文件的提交.

你也可以使用git mergetool, 它允许你使用外部工具如emacskdiff3去合并文件.

 

每次你解决冲突之后, 应该更新索引:

$ git add file.txt

完成索引更新之后, git-diff(缺省地)不再显示那个文件的差异,所以那个文件的不同暂存版本会被"折叠"起来.

六、多路合并

你可以一次合并多个头, 只需简单地把它们作为git merge的参数列出.例如,

$ git merge scott/master rick/master tom/master

相当于:

$ git merge scott/master

$ git merge rick/master

$ git merge tom/master

七、子树

有时会出现你想在自己项目中引入其他独立开发项目的内容的情况. 在没有路径冲突的前提下, 你只需要简单地从其他项目拉取内容即可.

如果有冲突的文件, 那么就会出现问题.可能的例子包括Makefile和其他一些标准文件名.你可以选择合并这些冲突的文件,但是更多的情况是你不愿意把它们合并.一个更好解决方案是把外部项目作为一个子目录进行合并.这种情况不被递归合并策略所支持,所以简单的拉取是无用的.

在这种情况下, 你需要的是子树合并策略.

这下面例子中, 我们设定你有一个仓库位于/path/to/B (如果你需要的话,也可以是一个URL).你想要合并那个仓库的master分支到你当前仓库的dir-B子目录下.

下面就是你所需要的命令序列:

$ git remote add -f Bproject /path/to/B (1)

$ git merge -s ours --no-commit Bproject/master (2)

$ git read-tree --prefix=dir-B/ -u Bproject/master (3)

$ git commit -m "Merge B project as our subdirectory" (4)

$ git pull -s subtree Bproject master (5)

子树合并的好处就是它并没有给你仓库的用户增加太多的管理负担. 它兼容于较老(版本号小于1.5.2)的客户端,克隆完成之后马上可以得到代码.

然而, 如果你使用子模块(submodule),你可以选择不传输这些子模块对象.这可能在子树合并过程中造成问题.

译者注: submoduleGit的另一种将别的仓库嵌入到本地仓库方法.

另外, 若你需要修改内嵌外部项目的内容,使用子模块方式可以更容易地提交你的修改

 git push -u origin v1.0.0 -f强制更新

编辑注释 git commit --amend

 

有个疑问?

Git 多个分支后,本地如何选择那个分支的代码进行使用?

比如我现在有两个分支,master 1.0.0,我想要工1.0.0的代码,如何取得?

 

 

 

git中,我们其实可以通过^~来定位某个具体的commit,而不用每次都去敲繁琐的hash值。为了便于大家理解,先把结论放在前面:

1.^”代表父提交,当一个提交有多个父提交时,可以通过在”^”后面跟上一个数字,表示第几个父提交,”^”相当于”^1.

2. ~<n>相当于连续的<n>个”^.

3. checkout只会移动HEAD指针,reset会改变HEAD的引用值。

 

 

 

这三大部分中:
working tree:就是你所工作在的目录,每当你在代码中进行了修改,working tree的状态就改变了。
index file:是索引文件,它是连接working treecommit的桥梁,每当我们使用git-add命令来登记后,index file的内容就改变了,此时index file就和working tree同步了。
commit:是最后的阶段,只有commit了,我们的代码才真正进入了git仓库。我们使用git-commit就是将index file里的内容提交到commit中。
总结一下:
git diff:是查看working treeindex file的差别的。
git diff --cached:是查看index filecommit的差别的。
git diff HEAD:是查看working treecommit的差别的。(你一定没有忘记,HEAD代表的是最近的一次commit的信息)

 

 

 

 

git diff HEAD

上面这条命令会显示你工作目录与上次提交时之间的所有差别,这条命令所显示的 内容都会在执行"git commit -a"命令时被提交。

 

git diff HEAD^

上面这条命令会显示你工作目录与上上次提交时之间的所有差别

 

但是为什么不能用git diff HEAD^2以上的呢????

 

 

 git diff --stat

如果不是查看每个文件的详细差别,而是统计一下有哪些文件被改动,有多少行被改 动,就可以使用--stat' 参数

 

查看HEAD和引用的值

我们可以通过命令来查看HEAD和引用的值,也可以通过当前仓库下的.git目录去访问。当前分支为master时,我们查看HEAD的值,命令如下:

$ cat .git/HEAD ref: refs/heads/master

 然后,我们可以查看master引用的值

$ cat .git/refs/heads/master3b0370b.......  # hash code

 

 

Git检出制定版本

问题:Git采用分布式版本管理,不需要像SVN每一个分支都是一个完整项目。当我们需要找出某个版本或者某次提交时的版本时,应该怎么操作?

解决:这里列举一个实例,本地没有版本需要从服务器检出指定某次提交是的版本

本示例就拿git@china做演示

 

第一步:先从服务器上找到版本提交日志 具体到哪一天 哪一次提交

左边的字符串就是你提交那次版本

第二步:

本地创建一个文件夹 clone出你的项目

第三部:通过IDE开发工具打开,便发现是你所要的版本,很简单吧,开始习惯使用git

 

今天碰到一个问题,git reset HEAR^后,不知道如何处理了。最后git pull居然冲突,最后撤销本地修改git reset hard还是不行,最后网上搜了下

解决git冲突造成的Please move or remove them before you can merge

git clean -d -fx ""
其中
x -----删除忽略文件已经对git来说不识别的文件
d -----删除未被添加到git的路径中的文件
f -----强制运行

不知道会产生什么影响

其实有些文件未被加入git的话,可以用git status来查看。然后采取措施。

 

获取远程新分支,如果用命令行,运行 git fetch,可以将远程分支信息获取到本地,再运行git checkout -b local-branchname origin/remote_branchname 

 

Get fetch 获取所有的远程分支到本地,然后通过git branch -a可以查看到所有的远程分支

获取远程分支到本地

Git fetch origin branch

查看的方法是 origin/branch,,比如对比远程分支与本地分支的区别

可以git diff branch_local orgin/branch

 

上面的操作也可这也

git fetch origin master:tmp创建一个临时分支
git diff tmp 查看与本地分支的区别
git merge tmp 合并到本地分支

 

查看两个版本的区别

Git log -p v1.0.0.. Origin/v2.0.0但不清楚能看出哪些不同

 

 

git log --oneline B ^A 可以列出B分支有而A分支没有的提交
git log --oneline A ^B 可以列出A分支有而B分支没有的提交

 

git log dev...master 不知道谁提交的多谁提交的少,单纯想知道有什么不一样:

master分支合并到feature分支最简单的办法就是用下面这些命令:

git checkout feature

git merge master

或者,你也可以把它们压缩在一行里。

git merge master feature

Your local changes to the following files would be overwritten by merge
error: Your local changes to the following files would be overwritten by merge:

        protected/config/main.php
Please, commit your changes or stash them before you can merge.


参考http://blog.youkuaiyun.com/zwhfyy/article/details/8625228


如果希望保留生产服务器上所做的改动,仅仅并入新配置项,处理方法如下:


git stash
git pull
git stash pop
然后可以使用git diff -w +文件名 来确认代码自动合并的情况.


反过来,如果希望用代码库中的文件完全覆盖本地工作版本.方法如下:


git reset --hard
git pull
其中git reset是针对版本,如果想针对文件回退本地修改,使用

untracked working tree file
参考:http://blog.youkuaiyun.com/sheismylife/article/details/7204345
编写脚本自动编译并部署时的注意

如果想在C2上编写脚本自动从S1上获取最新代码时,要注意:

1.首先之前产生的公钥不能设密码,否则每次git pull的时候都会要求输入密码。

2.不要将项目中的编译中间文件提交到S1上,比如CMake工程里面的build目录的文件,Maven工程里面的target目录里面的文件。否则下次在C2等客户端用git pull会报类似于这样的错误:

error: Untracked working tree file 'public/images/icon.gif' would be overwritten by merge.
需要执行下面的命令才能修复:


git reset --hard HEAD    
git clean -f -d    
git pull  

 

git reset soft,hard,mixed之区别深解

时间:2015-05-19 00:28:42      阅读:8288      评论:0      收藏:0      [点我收藏+]

标签:class   style   log   com   使用   src   http   it   文件   

GIT reset命令,似乎让人很迷惑,以至于误解,误用。但是事实上不应该如此难以理解,只要你理解到这个命令究竟在干什么。

首先我们来看几个术语

HEAD

这是当前分支版本顶端的别名,也就是在当前分支你最近的一个提交

Index

index也被称为staging area,是指一整套即将被下一个提交的文件集合。他也是将成为HEAD的父亲的那个commit

Working Copy

working copy代表你正在工作的那个文件集

Flow

当你第一次checkout一个分支,HEAD就指向当前分支的最近一个commit。在HEAD中的文件集(实际上他们从技术上不是文件,他们是blobs(一团),但是为了讨论的方便我们就简化认为他们就是一些文件)和在index中的文件集是相同的,在working copy的文件集和HEAD,INDEX中的文件集是完全相同的。所有三者(HEAD,INDEX(STAGING),WORKING COPY)都是相同的状态,GIThappy

当你对一个文件执行一次修改,Git感知到了这个修改,并且说:“嘿,文件已经变更了!你的working copy不再和index,head相同!”,随后GIT标记这个文件是修改过的。

然后,当你执行一个git add,它就stages the file in the index,并且GIT说:“嘿,OK,现在你的working copyindex区是相同的,但是他们和HEAD区是不同的!”

当你执行一个git commit,GIT就创建一个新的commit,随后HEAD就指向这个新的commit,而index,working copy的状态和HEAD就又完全匹配相同了,GIT又一次HAPPY了。

Reset

如果你仔细研究reset命令本身就知道,它本身做的事情就是重置HEAD(当前分支的版本顶端)到另外一个commit。假设我们有一个分支(名称本身无所谓,所以我们就简单称为"super-duper-feature”分支吧),图形化表示如下:

如果我们执行:

git reset HEAD

任何事情都不会发生,这是因为我们告诉GIT重置这个分支到HEAD,而这个正是它现在所在的位置。

git reset HEAD~1

当我们再执行上面的命令时(HEAD~1是“the commit right before HEAD”的别名,或者说:put differently "HEADs parent"),我们的分支将会如下所示

如果我们执行git reset HEAD~2,则意味着将HEAD从顶端的commit往下移动两个更早的commit

Parameters

soft

--soft参数告诉Git重置HEAD到另外一个commit,但也到此为止。如果你指定--soft参数,Git将停止在那里而什么也不会根本变化。这意味着index,working copy都不会做任何变化,所有的在original HEAD和你重置到的那个commit之间的所有变更集仍然在stage(index)区域中。

 

2.hard

--hard参数将会blow out everything.它将重置HEAD返回到另外一个commit(取决于~12的参数),重置index以便反映HEAD的变化,并且重置working copy也使得其完全匹配起来。这是一个比较危险的动作,具有破坏性,数据因此可能会丢失!如果真是发生了数据丢失又希望找回来,那么只有使用:git reflog命令了

3.mixed(default

--mixedreset的默认参数,也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD比配,但是也到此为止。working copy不会被更改。所以所有从original HEAD到你重置到的那个commit之间的所有变更仍然保存在working copy中,被标示为已变更,但是并未staged的状态

 

git reset soft,hard,mixed之区别深解

 

 

Git Stash用法

最近在使用Git管理项目工程的时候,遇到了很多问题,也学习到了很多关于Git常见使用的技巧,下面就其中关于Git Stash的用法和大家分享下。
首先,简单介绍下Git Stash命令的用法,详细的用法在man文档中有相关介绍,下面我来说明常见的使用。
git stash: 备份当前的工作区的内容,从最近的一次提交中读取相关内容,让工作区保证和上次提交的内容一致。同时,将当前的工作区内容保存到Git栈中。
git stash pop: Git栈中读取最近一次保存的内容,恢复工作区的相关内容。由于可能存在多个Stash的内容,所以用栈来管理,pop会从最近的一个stash中读取内容并恢复。
git stash list: 显示Git栈内的所有备份,可以利用这个列表来决定从那个地方恢复。
git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现,原来stash的哪些节点都消失了。
关于Git Stash的详细解释,适用场合,这里做一个说明:

使用git的时候,我们往往使用branch解决任务切换问题,例如,我们往往会建一个自己的分支去修改和调试代码如果别人或者自己发现原有的分支上有个不得不修改的bug,我们往往会把完成一半的代码 commit提交到本地仓库,然后切换分支去修改bug,改好之后再切换回来。这样的话往往log上会有大量不必要的记录。其实如果我们不想提交完成一半或者不完善的代码,但是却不得不去修改一个紧急Bug,那么使用'git stash'就可以将你当前未提交到本地(和服务器)的代码推入到Git的栈中,这时候你的工作区间和上一次提交的内容是完全一样的,所以你可以放心的修 Bug,等到修完Bug,提交到服务器上后,再使用'git stash apply'将以前一半的工作应用回来。也许有的人会说,那我可不可以多次将未提交的代码压入到栈中?答案是可以的。当你多次使用'git stash'命令后,你的栈里将充满了未提交的代码,这时候你会对将哪个版本应用回来有些困惑,'git stash list'命令可以将当前的Git栈信息打印出来,你只需要将找到对应的版本号,例如使用'git stash apply stash@{1}'就可以将你指定版本号为stash@{1}的工作取出来,当你将所有的栈都应用回来的时候,可以使用'git stash clear'来将栈清空。
在这里顺便提下git format-patch -n , n是具体某个数字, 例如 'git format-patch -1' 这时便会根据log生成一个对应的补丁,如果 'git format-patch -2' 那么便会生成2个补丁,当然前提是你的log上有至少有两个记录。


看过上面的信息,就可以知道使用场合了:当前工作区内容已被修改,但是并未完成。这时Boss来了,说前面的分支上面有一个Bug,需要立即修复。可是我又不想提交目前的修改,因为修改没有完成。但是,不提交的话,又没有办法checkout到前面的分支。此时用Git Stash就相当于备份工作区了。然后在Checkout过去修改,就能够达到保存当前工作区,并及时恢复的作用。

下面,将我使用过程中遇到的一个问题和大家分享:

首先,在Git Stash之后,提交图如下所示:

从图中可以看到,developnewdevelop是在同一个分支上,因为分支newdevelop是在develop分支的基础上开发的。想加入一个新的特性,所以就开了newdevelop分支,然后就在上面加东西,加特性,该代码。这个时候工作的内容已经变化了,但是developnewdevelop都是指向同一个提交的,因为newdevelop上面还木有提交。
这个时候,Boss来了,说develop上面有个Bug,赶快改一下,手头的工作先放放,稳定版本不能有缺陷。没办法,当前正在newdevelop上搞的high呢,就Git Stash一下。所以会看到上面有两个节点,红色以及上面一个。就是stash之后的结果,注意是在newdevelop上面进行的stash

正如前面所说,stash会暂存当前的工作区内容,然后将工作区内容保持和上次提交相同,此时内容都是上面8a32那个提交的内容。从终端中查看相应的信息内容,如下:

印证了签名的说法,newdevelop是有修改,modified,然后stash之后,工作区是最近一次提交,此时newdevelopdevelop都是相同的,所以再git status查看发现,都一样,nothing to commit.

然后Stash完成之后,就要Fix Bug了。为此,回到develop分支上进行修复,然后提交,完成后的提交图如下所示:

 

从途中可以看到,newdevelop还是在下面,因为指向的是老的那个8a32commit。新的develop由于修复了Bug,所以产生一个新提交。


然后在develop上面修复了Bug之后,在回到newdevelop上面进行一个新的特性的继续编码,此时checkout回去的时候,没有神马内容可以提交,因为都存在Stash中了,没有任何修改。如上图。

那么,恢复工作区内容吧。于是git stash pop(注意这里由于只Stash了一次所以使用pop,具体你存放了多少,要恢复哪一个要自己清楚,否则会出错!)

恢复之后,从上图中可以看到,此时再git status就会发现文件有修改,说明恢复过来了。然后就继续编码,提交一个稳定的新特性版本,如下图,产生的新提交为0906.
然后再查看提交图,会发现,stash pop之后,对应的存放的stash被清空掉了,提交图中,newdevelop上面对应一个新的提交。并且在develop上面。分支的develop那个红色,即为前面修复Bug的那个提交。


总结起来:
操作很简单,但是头脑要清楚。要在哪个分支上修复Bug,要暂存哪个地方的内容,之后修复完了在那个地方提交,然后要到哪个分支上面恢复工作区,都是需要注意的,否则,很容易造成提交图混乱。只有弄清楚了工作流程,才不容易出错,才能保证很高的工作效率。
最后一句:Git是神器,就要看你如何驾驭它了。

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值