廖雪峰老师关于github的微博: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013744142037508cf42e51debf49668810645e02887691000
刚学习了下github的基本命令, 在github上运用了一下, 防止记忆力不好 就记录一下。
首先是 命令 $ git add XXX , 该语句是将改变提交到暂存区
首先要保证文件XXX是存在目录下的
然后 $ git commit -m "history name" 提交改变, “history name ” 是这次提交的改变的log的名字, 像svn一样 , 为这次改变取一个名字,
这句将所改变的东西提交到master
$ git push origin master 运行成功后再看网页中的github目录 就会有了提交的改变
$ git log 可以看到之前的历史变更记录 ,如果感觉看起来太多
$ git log --pretty=oneline
--pretty=oneline 参数
首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD
表示当前版本,也就是最新的提交3628164...882e1e0
(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
。
现在,我们要把当前版本“append GPL”回退到上一个版本“add distributed”,就可以使用
git reset
命令:$ git reset --hard HEAD^ HEAD is now at ea34578 add distributed
想要回到未来的版本需要时用 $ git reflog 命令查看历史版本
git diff HEAD -- readme.txt使用 $ git diff 可以查看最新版和历史版本的区别
你可以发现,Git会告诉你,
git checkout -- file
可以丢弃工作区的修改:$ git checkout -- readme.txt
命令
git checkout -- readme.txt
意思就是,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:一种是
readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;一种是
readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。总之,就是让这个文件回到最近一次
git commit
或git add
时的状态。
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令
git checkout -- file
。场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令
git reset HEAD file
,就回到了场景1,第二步按场景1操作。场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
关联一个远程的库
要关联一个远程库,使用命令
git remote add origin git@github.com:your_name/repo_name.git
;关联后,使用命令
git push -u origin master
第一次推送master分支的所有内容;此后,每次本地提交后,只要有必要,就可以使用命令
git push origin master
推送最新修改;
下面讲述的是 不同分支的创建于合并,并且在分支与master产生冲突时, 如何解决冲突后提交
人生不如意之事十之八九,合并分支往往也不是一帆风顺的。
准备新的
feature1
分支,继续我们的新分支开发:$ git checkout -b feature1 Switched to a new branch 'feature1'
修改readme.txt最后一行,改为:
Creating a new branch is quick AND simple.
在
feature1
分支上提交:$ git add readme.txt $ git commit -m "AND simple" [feature1 75a857c] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)
切换到
master
分支:$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit.
Git还会自动提示我们当前
master
分支比远程的master
分支要超前1个提交。在
master
分支上把readme.txt文件的最后一行改为:Creating a new branch is quick & simple.
提交:
$ git add readme.txt $ git commit -m "& simple" [master 400b400] & simple 1 file changed, 1 insertion(+), 1 deletion(-)
现在,
master
分支和feature1
分支各自都分别有新的提交,变成了这样:这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:
$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.
果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。
git status
也可以告诉我们冲突的文件:$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a")
我们可以直接查看readme.txt的内容:
Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. <<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. >>>>>>> feature1
Git用
<<<<<<<
,=======
,>>>>>>>
标记出不同分支的内容,我们修改如下后保存:Creating a new branch is quick and simple.
再提交:
$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed
现在,
master
分支和feature1
分支变成了下图所示:用带参数的
git log
也可以看到分支的合并情况:$ git log --graph --pretty=oneline --abbrev-commit * 59bc1cb conflict fixed |\ | * 75a857c AND simple * | 400b400 & simple |/ * fec145a branch test ...
最后,删除
feature1
分支:$ git branch -d feature1 Deleted branch feature1 (was 75a857c).
准备合并
dev
分支,请注意--no-ff
参数,表示禁用Fast forward
:$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,
master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在
dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;你和你的小伙伴们每个人都在
dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。所以,团队合作的分支看起来就像这样:
在进行bug修复时,需要临时保存做的修改等
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场
git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场。
你的小伙伴要在
dev
分支上开发,就必须创建远程origin
的dev
分支到本地,于是他用这个命令创建本地dev
分支$ git checkout -b dev origin/dev
多人协作共同开发一个项目时,工作流程是这样的
多人协作的工作模式通常是这样:
首先,可以试图用
git push origin branch-name
推送自己的修改;如果推送失败,则因为远程分支比你的本地更新,需要先用
git pull
试图合并;如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用
git push origin branch-name
推送就能成功!如果
git pull
提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name
。这就是多人协作的工作模式,一旦熟悉了,就非常简单。
小结
查看远程库信息,使用
git remote -v
;本地新建的分支如果不推送到远程,对其他人就是不可见的;
从本地推送分支,使用
git push origin branch-name
,如果推送失败,先用git pull
抓取远程的新提交;在本地创建和远程分支对应的分支,使用
git checkout -b branch-name origin/branch-name
,本地和远程分支的名称最好一致;建立本地分支和远程分支的关联,使用
git branch --set-upstream branch-name origin/branch-name
;从远程抓取分支,使用
git pull
,如果有冲突,要先处理冲突