七、Git命令解析

一、建立版本库

cd E:
mkdir myRepository
pwd
ls -ah
======
git init

二、添加文件到仓库

添加
git add readme.txt
提交
git commit -m "i wrote a readme file"

【为何Git添加文件须要add，commit一共两步呢？由于commit能够一次提交不少文件，因此你能够屡次add不一样的文件
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."】

$ git status
【git status命令可让咱们时刻掌握仓库当前的状态，上面的命令输出告诉咱们，readme.txt被修改过了，但尚未准备提交的修改。】
$ git diff readme.txt
【git diff顾名思义就是查看difference，显示咱们在第一行添加了一个distributed单词。】

$ git add readme.txt
$ git commit -m "add distributed"

三、回退版本

$ git log
【git log命令显示从最近到最远的提交日志】
$ git log --pretty=oneline
【一行显示，前边的是提交的commit id版本号】
$git reset --hard HEAD^
【回退到上个版本号】
$git reset --hard 54897
【回退到某个版本】
【Git的版本回退速度很是快，由于Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：
而后顺便把工做区的文件更新了。因此你让HEAD指向哪一个版本号，你就把当前版本定位在哪】
$ git reflog
【Git提供了一个命令git reflog用来记录你的每一次命令】

四、工做区和暂存区

工做区
【工做区就是你在电脑里能看到的目录，好比个人myRepository文件夹就是一个工做区】
版本库
【工做区有一个隐藏目录.git，这个不算工做区，而是Git的版本库。】
Git的版本库里存了不少东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为咱们自动建立的第一个分支master，以及指向master的一个指针叫HEAD。

【第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区】
【第二步是用git commit提交更改，实际上就是把暂存区的全部内容提交到当前分支。】
【由于咱们建立Git版本库时，Git自动为咱们建立了惟一一个master分支，因此，如今，git commit就是往master分支上提交更改。】

五、撤销修改
 

git checkout -- readme.txt
【--后有空格】
【一种是readme.txt自修改后尚未被放到暂存区，如今，撤销修改就回到和版本库如出一辙的状态；】
【一种是readme.txt已经添加到暂存区后，又做了修改，如今，撤销修改就回到添加到暂存区后的状态。】
$ git reset HEAD readme.txt
【将暂存区的代码撤销掉，从新放回工做区，HEAD为最新的分支中的版本】



场景1：当你改乱了工做区某个文件的内容，想直接丢弃工做区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工做区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操做。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

六、删除
 

rm licence.txt
【本地先删除】
git rm licence.txt
【从版本库中删除】
git commit
【提交删除】
==============
没提交以前想回退删除：
$ git log --pretty=oneline
$ git reset --hard a2bd3a

 

七、注意

git status

Changes not staged for commit
【表示没有提交到暂存区,想回退用git checkout --file】
Changes to be committed:
【表示提交到了暂存区,想回退先用git reset HEAD <file>    而后   git checkout  --file】

 八、远程推送

$ git remote add origin https://gitee.com/night_wish/myRepository.git
【添加到远程仓库】
【添加后，远程库的名字就是origin，这是Git默认的叫法，也能够改为别的，可是origin这个名字一看就知道是远程库。】
$ git push -u origin master
【第一次推送到远程仓库 master分支】
$ git push origin master
【之后推送远程仓库master分支】
$ git clone git@gitee.com:night_wish/myRepository.git
【克隆远程仓库】

九、分支

分支在实际中有什么用呢？假设你准备开发一个新功能，可是须要两周才能完成，第一周你写了50%的代码，若是马上提交，因为代码还没写完，不完整的代码库会致使别人不能干活了。若是等代码所有写完再一次提交，又存在丢失天天进度的巨大风险。

如今有了分支，就不用怕了。你建立了一个属于你本身的分支，别人看不到，还继续在原来的分支上正常工做，而你在本身的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工做。



$ git checkout -b dev
【建立一个dev分支,并切换到dev -b表示建立并切换】
$git branch dev
【建立dev分支】
$git checkout dev
【切换到dev分支】
$git branch
【查看全部分支，当前分支前面会有*】
$ git merge dev
【合并dev分支到当前分支】
$ git branch -d dev
【删除dev分支】
$ git branch -D feature-vulcan
【强行删除分支】

十、分支策略

在实际开发中，咱们应该按照几个基本原则进行分支管理：
首先，master分支应该是很是稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，好比1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每一个人都在dev分支上干活，每一个人都有本身的分支，时不时地往dev分支上合并就能够了。
因此，团队合做的分支看起来就像这样

 

十一、修复bug

软件开发中，bug就像屡见不鲜同样。有了bug就须要修复，在Git中，因为分支是如此的强大，因此，每一个bug均可以经过一个新的临时分支来修复，修复后，合并分支，而后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很天然地，你想建立一个分支issue-101来修复它，可是，等等，当前正在dev上进行的工做尚未提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt
并非你不想提交，而是工做只进行到一半，还无法提交，预计完成还需1天时间。可是，必须在两个小时内修复该bug，怎么办？

幸亏，Git还提供了一个stash功能，能够把当前工做现场“储藏”起来，等之后恢复现场后继续工做：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
如今，用git status查看工做区，就是干净的（除非有没有被Git管理的文件），所以能够放心地建立分支来修复bug。

首先肯定要在哪一个分支上修复bug，假定须要在master分支上修复，就从master建立临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'
如今修复bug，须要把“Git is free software ...”改成“Git is a free software ...”，而后提交：

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
太棒了，原计划两个小时的bug修复只花了5分钟！如今，是时候接着回到dev分支干活了！

$ git checkout dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean
工做区是干净的，刚才的工做现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工做现场还在，Git把stash内容存在某个地方了，可是须要恢复一下，有两个办法：

一是用git stash apply恢复，可是恢复后，stash内容并不删除，你须要用git stash drop来删除；

另外一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash内容了：

$ git stash list
你能够屡次stash，恢复的时候，先用git stash list查看，而后恢复指定的stash，用命令：

$ git stash apply stash@{0}