git

meng_qu_qu 贡献于2016-06-08

作者 homelink  创建于2016-06-02 05:20:00   修改者homelink  修改于2016-06-03 09:19:00字数1816

文档摘要:使用pull从远程更新代码时,会获取到远程指定分支的更新并合并到本地指定的分支,一般情况下不需要指定,默认把本地当前分支对应的远程分支的更新获取到并跟本地的当前分支合并。
关键词:

1 git pull 与git pull –rebase 使用pull从远程更新代码时,会获取到远程指定分支的更新并合并到本地指定的分支,一般情况下不需要指定,默认把本地当前分支对应的远程分支的更新获取到并跟本地的当前分支合并。在多人协作的场景中,不推荐使用git pull,尽量用git pull –r 或者git pull --rebase. Rebase是重新定义(re)起点(base)的作用。 当前的远程分支是这样的:  origin dev:A—B—C—D 此时我把dev拉到本地,进行开发,开发完成commit后我本地是这样的:  A—B—C—D—E—F 而此时dev分支可能还有别的同事在开发,并且已经提交了他的修改,现在origin dev分支是这样的:  A—B—C—D—G—H 执行git pull后,仓库里的分支曲线是这样的:  时间久了这条曲线就会非常混乱。如果此时用git pull - - rebase,结果是这样的:  A—B—C—D—G—H—E’—F’,依然保持一条直线,看上去很整洁。 但是使用git pull和git pull - - rebase都有可能产生conflicts,这个是不可避免的,乖乖的解决冲突就好了。  如果要把 rebase当做 git pull 的默认值,可以在 ~/.gitconfig 配置让所都自动套用这个设定:  [branch]  autosetuprebase = always 2、撤销修改 如果要让工作目录回到上次提交时的状态,执行 git reset –hard HEAD 如果要恢复某一个文件,执行 git checkout – path/of/the/file  reset这个命令有三个参数可选:soft mixed hard,这三个参数分别是什么意思呢?  首先我们要理解三个概念: 1. HEAD,是一个指向当前分支最后一次提交的一个指针 2. Index,也就是staging area(暂存区),是存放即将被提交的文件的地方 3. Working Copy,当前工作目录下的文件 当我们第一次checkout一个远程分支时,HEAD指向该分支上最后一个commit,他和Index和Working Copy是一样的。  当我修改了一个文件,Working Copy和Index、HEAD就不一致了,这时Git会提示我们文件有修改;  当我add这个文件后,Working Copy 和Index一样了,而他俩又和HEAD不一致了,这时Git会提示我们有文件可以提交了  当我commit这个文件后,HEAD指向了刚创建的这次commit,Working Copy和Index和HEAD又一样了。  那么,这三个参数的区别就是: · soft:告诉Git只将HEAD重置到某个commit,Working Copy和Index都不变动; · mixed:HEAD和Index都改变,Working Copy中的文件不变动,此时会提示文件有修改,但是没有缓存到暂存区; · hard:三者都改变到你要reset的那个commit上,这可能会导致你本地的修改丢失。 3、关于stash 当我在一个feature分支上开发时,突然反馈了一个bug,这时我需要切换到dev分支来修改这个bug,但此时在feature分支上的修改还没有做完,不想提交,此时可以使用git stash,将本地的修改先隐藏起来,不让Git发现,这时就可以checkout到dev分支,此时查看status你会发现Working Copy是clean的,可以任意发挥了。当改完bug后再切换回feature分支,执行git stash pop 来恢复之前隐藏的那些修改,这时我又可以继续feature上的开发了。 还有就是在提交代码之前,会更新远程最新代码到本地,这时候git stash 保存本地代码到缓存区,万一中途误操作,导致代码丢失,更新完了,之后git stash pop取缓存区代码。 4、cherry-pick 这个命令可以帮助我们把另一个分支的某个commit提交到当前的分支,而不必把整个分支都合并一次。想象一个场景:我们正在进行新版本的迭代开发,此时准备发布的版本突然被发现一个bug,而这个bug已经在新版本开发中修复了,但是又不能直接把新版本的分支合并到待发布的分支上,此时可以使用git cherry-pick commitid,将新版本分支中 的那次commit提交到待发布的分支上,这样既修复了bug,又没有污染待发布的分支。但是这个命令是有风险的,可能会造成冲突,应该谨慎使用

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档