Git 使用教程，最详细，最傻瓜，最浅显，小姐姐真正手把手教会你

• 本地使用Git，都需要先配置下自己仓库的邮箱和用户名，基本只使用一次

  • git config --global user.email “you@example.com”
  • git config --global user.name “Your Name”

  常用命令

  • git clone #克隆远程版本库

  • git init #初始化本地仓库

  • git status #查看下仓库的当前的状态

  • git add / . #跟踪指定文件或所有改动过的文件

  • git commit -m “commit message” # 提交所有更新过的文件

  • git log #查看提交历史日志

  • git relog #查看所有操作记录日志，回退穿越很有用

  • git reset --hard HEAD # 回退

  • git pull # 拉取代码并快速合并

  • git push # 推送代码及快速合并

  • git fetch / --all # 获取指定远程仓库或所有远程仓库代码

  • git merge # 合并指定分支到当前分支

  git clone到本地

  • 在对项目进行“git clone”之前,是否需要“git init”

    • git克隆基本上是一个组合：

      it init(创建本地存储库)
      git remote add(将URL添加到该存储库)
      git fetch(从该URL中获取所有分支到本地存储库)
      git checkout(创建工作树中主分支的所有文件)

      所以不需要

      而且已经给远程库起了别名

• git diff

• git log [–pretty=oneline]

• git reset --hard HEAD^ | HEAD^^^ | 前四位

• git reflog 可以找到提交的commit id

• git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支

• 用git diff HEAD -- readme.txt命令可以查看(工作区 暂存区)和版本库里面最新版本的区别

• git checkout -- readme.txt  #就是让这个文件回到最近一次git commit或git add时的状态

  命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

  一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

  一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态

  **git checkout其实是用版本库里的版本替换工作区的版本 已添加到暂存区的除外 ** 是让这个文件回到最近一次git commit或git add时的状态

• 修改只是添加到了暂存区，还没有提交 用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区

• 一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

  $ git rm test.txtrm 'test.txt'$ git commit -m "remove test.txt"[master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt

  另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

• $ git checkout -- test.txt

  git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”

创建与合并分支

• 查看分支：git branch

  创建分支：git branch <name>

  切换分支：git checkout <name>或者git switch <name>

  创建+切换分支：git checkout -b <name>或者git switch -c <name>

  合并某分支到当前分支：git merge <name>

  删除分支：git branch -d <name>

• 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b devSwitched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev$ git checkout devSwitched to branch 'dev'

把dev分支的工作成果合并到master分支上：

$ git merge devUpdating d46f35e..b17d20eFast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d devDeleted branch dev (was b17d20e).

删除后，查看branch，就只剩下master分支了：

$ git branch* master

解决冲突

• 准备新的feature1分支，继续我们的新分支开发：

  $ git switch -c feature1Switched 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 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)

  切换到master分支：

  $ git switch masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 1 commit.  (use "git push" to publish your local commits)

  Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

  在master分支上把readme.txt文件的最后一行改为：

  Creating a new branch is quick & simple.

  提交：

  $ git add readme.txt $ git commit -m "& simple"[master 5dc6824] & simple 1 file changed, 1 insertion(+), 1 deletion(-)

  现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
  

  这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

  $ git merge feature1Auto-merging readme.txtCONFLICT (content): Merge conflict in readme.txtAutomatic merge failed; fix conflicts and then commit the result.

  果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

  $ git statusOn branch masterYour branch is ahead of 'origin/master' by 2 commits.  (use "git push" to publish your local commits)You have unmerged paths.  (fix conflicts and run "git commit")  (use "git merge --abort" to abort the merge)Unmerged paths:  (use "git add <file>..." to mark resolution)	both modified:readme.txtno 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.<<<<<<< HEADCreating 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 cf810e4] conflict fixed

  现在，master分支和feature1分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit*cf810e4 (HEAD -> master) conflict fixed|\  | * 14096d0 (feature1) AND simple* | 5dc6824 & simple|/  * b17d20e branch test* d46f35e (origin/master) remove test.txt* b84166e add test.txt* 519219b git tracks changes* e43a48b understand how stage works* 1094adb append GPL* e475afc add distributed* eaadf4e wrote a readme file

最后，删除feature1分支：

$ git branch -d feature1Deleted branch feature1 (was 14096d0).

工作完成。

Fast forward模式

• git merge --no-ff -m "merge with no-ff" dev

  通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

  如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

  下面我们实战一下--no-ff方式的git merge：

  首先，仍然创建并切换dev分支：

  $ git switch -c devSwitched to a new branch 'dev'

  修改readme.txt文件，并提交一个新的commit：

  $ git add readme.txt $ git commit -m "add merge"[dev f52c633] add merge 1 file changed, 1 insertion(+)

  现在，我们切换回master：

  $ git switch masterSwitched to branch 'master'

  准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

  $ git merge --no-ff -m "merge with no-ff" devMerge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)

  因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

  合并后，我们用git log看看分支历史：

  $ git log --graph --pretty=oneline --abbrev-commit*e1e9c68 (HEAD -> master) merge with no-ff|\  | * f52c633 (dev) add merge|/  *cf810e4 conflict fixed...

  可以看到，不使用Fast forward模式，merge后就像这样：

git stash 保存现场

• 件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

  当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交

• Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

  $ git stashSaved working directory and index state WIP on dev: f52c633 add merge

• 首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

  $ git checkout masterSwitched 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-101Switched 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 switch masterSwitched 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-101Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

  太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

  $ git switch devSwitched to branch 'dev'$ git statusOn branch devnothing to commit, working tree clean

  工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

  $ git stash liststash@{0}: WIP on dev: f52c633 add merge

  工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

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

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

  $ git stash popOn branch devChanges to be committed:  (use "git reset HEAD <file>..." to unstage)	new file:hello.pyChanges 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.txtDropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

  再用git stash list查看，就看不到任何stash内容了：

  $ git stash list

  你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

  $ git stash apply stash@{0}

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？

有木有更简单的方法？

有！

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch* dev  master$ git cherry-pick 4c805e2[master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

• 分支不要了，但没有合并 要删除的话需要—D

  • 一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。

  但是！

  就在此时，接到上级命令，因经费不足，新功能必须取消！

  虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：

  $ git branch -d feature-vulcanerror: The branch 'feature-vulcan' is not fully merged.If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

  销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。

  现在我们强行删除：

  $ git branch -D feature-vulcanDeleted branch feature-vulcan (was 287773e).

  终于删除成功！

多人协作

• 当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

  要查看远程库的信息，用git remote：

  $ git remoteorigin

  或者，用git remote -v显示更详细的信息：

  $ git remote -vorigin  git@github.com:michaelliao/leagit.git (fetch)origin  git@github.com:michaelliao/leagit.git (push)

  上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

  推送分支

  推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

  $ git push origin master

  如果要推送其他分支，比如dev，就改成：

  $ git push origin dev

  但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

  • master分支是主分支，因此要时刻与远程同步；
  • dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
  • bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
  • feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

  总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch* master

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

$ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

$ git add env.txt$ git commit -m "add env"[dev 7a5e5dd] add env 1 file changed, 1 insertion(+) create mode 100644 env.txt$ git push origin devCounting objects: 3, done.Delta compression using up to 4 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.Total 3 (delta 0), reused 0 (delta 0)To github.com:michaelliao/leagit.gitf52c633..7a5e5dd  dev -> dev

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

$ cat env.txtenv$ git add env.txt$ git commit -m "add new env"[dev 7bd91f1] add new env 1 file changed, 1 insertion(+) create mode 100644 env.txt$ git push origin devTo github.com:michaelliao/leagit.git ! [rejected]dev -> dev (non-fast-forward)error: failed to push some refs to 'git@github.com:michaelliao/leagit.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Integrate the remote changes (e.g.hint: 'git pull ...') before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

$ git pullThere is no tracking information for the current branch.Please specify which branch you want to merge with.See git-pull(1) for details.git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with:git branch --set-upstream-to=origin/<branch> dev

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

$ git branch --set-upstream-to=origin/dev devBranch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

$ git pullAuto-merging env.txtCONFLICT (add/add): Merge conflict in env.txtAutomatic merge failed; fix conflicts and then commit the result.

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

$ git commit -m "fix env conflict"[dev 57c53ab] fix env conflict$ git push origin devCounting objects: 6, done.Delta compression using up to 4 threads.Compressing objects: 100% (4/4), done.Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.Total 6 (delta 0), reused 0 (delta 0)To github.com:michaelliao/leagit.git7a5e5dd..57c53ab  dev -> dev

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <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，如果有冲突，要先处理冲突。

拉取远程分支并创建本地分支

• git checkout -b 本地分支名x origin/远程分支名x

  • 使用该方式会在本地新建分支x，并自动切换到该本地分支x。采用此种方法建立的本地分支会和远程分支建立映射关系。

• 使用如下命令：

  git fetch origin 远程分支名x:本地分支名x

  使用该方式会在本地新建分支x，但是不会自动切换到该本地分支x，需要手动checkout。采用此种方法建立的本地分支不会和远程分支建立映射关系。

用git checkout -b dev origin/dev这个命令

它意思是说.切换到dev分支上,接着跟远程的origin地址上的dev分支关联起来,这里要注意origin代表是一个路径,可以用git remote -v 查看

说来白了,origin/dev有点像是git@github.com:xxxxx/yyyyy.git/dev

接着在dev当前分支下进行操作,add,commit后,用git push origin dev,意思是推送当前的dev分支到远程origin地址的dev分支上

通常，git会将本地库分支与远程分支之间建立一种追踪关系。比如，在git clone的时候，所有本地分支默认与远程库的同名分支建立追踪关系。也就是说，本地的master分支自动追踪origin/master分支。因此，如果当前处于本地online分支上，并且本地online分支与远程的online分支有追踪关系，那么远程的分支名可以省略。本地使用checkout -b online 是创建的新onlne分支，而与服务器online根本不算是同一个分支，所以要从服务端拉取

rebase

• git rebase

  分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

TAG:

• Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

  Git有commit，为什么还要引入tag？

  “请把上周一的那个版本打包发布，commit号是6a5819e…”

  “一串乱七八糟的数字不好找！”

  如果换一个办法：

  “请把上周一的那个版本打包发布，版本号是v1.2”

  “好的，按照tag v1.2查找commit就行！”

  所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

• 在Git中打标签非常简单，首先，切换到需要打标签的分支上：

  $ git branch* dev  master$ git checkout masterSwitched to branch 'master'

  然后，敲命令git tag <name>就可以打一个新标签：

  $ git tag v1.0

  可以用命令git tag查看所有标签：

  $ git tagv1.0

  默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？

  方法是找到历史提交的commit id，然后打上就可以了：

  $ git log --pretty=oneline --abbrev-commit12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 1014c805e2 fix bug 101e1e9c68 merge with no-fff52c633 add mergecf810e4 conflict fixed5dc6824 & simple14096d0 AND simpleb17d20e branch testd46f35e remove test.txtb84166e add test.txt519219b git tracks changese43a48b understand how stage works1094adb append GPLe475afc add distributedeaadf4e wrote a readme file

  比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：

  $ git tag v0.9 f52c633

  再用命令git tag查看标签：

  $ git tagv0.9v1.0

  注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：

  $ git show v0.9commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)Author: Michael Liao <askxuefeng@gmail.com>Date:Fri May 18 21:56:54 2018 +0800add mergediff --git a/readme.txt b/readme.txt...

  可以看到，v0.9确实打在add merge这次提交上。

  还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

  $ git tag -a v0.1 -m "version 0.1 released" 1094adb

  用命令git show <tagname>可以看到说明文字：

  $ git show v0.1tag v0.1Tagger: Michael Liao <askxuefeng@gmail.com>Date:Fri May 18 22:48:43 2018 +0800version 0.1 releasedcommit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)Author: Michael Liao <askxuefeng@gmail.com>Date:Fri May 18 21:06:15 2018 +0800append GPLdiff --git a/readme.txt b/readme.txt...

• 命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；

• 命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；

• 命令git tag可以查看所有标签。

忽略特殊文件

• 有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

  好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

  不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

  忽略文件的原则是：

  1. 忽略操作系统自动生成的文件，比如缩略图等；
  2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
  3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

  举个例子：

  假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：

  # Windows:Thumbs.dbehthumbs.dbDesktop.ini

  然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：

  # Python:*.py[cod]*.so*.egg*.egg-infodistbuild

  加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：

  # Windows:Thumbs.dbehthumbs.dbDesktop.ini# Python:*.py[cod]*.so*.egg*.egg-infodistbuild# My configurations:db.inideploy_key_rsa

  最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。

  使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

  有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：

  $ git add App.classThe following paths are ignored by one of your .gitignore files:App.classUse -f if you really want to add them.

  如果你确实想添加该文件，可以用-f强制添加到Git：

  $ git add -f App.class

  或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：

  $ git check-ignore -v App.class.gitignore:3:*.class	App.class

  Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

  还有些时候，当我们编写了规则排除了部分文件时：

  # 排除所有.开头的隐藏文件:.*# 排除所有.class文件:*.class

  但是我们发现.*这个规则把.gitignore也排除了，并且App.class需要被添加到版本库，但是被*.class规则排除了。

  虽然可以用git add -f强制添加进去，但有强迫症的童鞋还是希望不要破坏.gitignore规则，这个时候，可以添加两条例外规则：

  # 排除所有.开头的隐藏文件:.*# 排除所有.class文件:*.class# 不排除.gitignore和App.class:!.gitignore!App.class

  把指定文件排除在.gitignore规则外的写法就是!+文件名，所以，只需把例外文件添加进去即可。

配置别名

• 有没有经常敲错命令？比如git status？status这个单词真心不好记。

  如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。

  我们只需要敲一行命令，告诉Git，以后st就表示status：

  $ git config --global alias.st status

  好了，现在敲git st看看效果。

  当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：

  $ git config --global alias.co checkout$ git config --global alias.ci commit$ git config --global alias.br branch

  以后提交就可以简写成：

  $ git ci -m "bala bala bala..."

  --global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。

  在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：

  $ git config --global alias.unstage 'reset HEAD'

  当你敲入命令：

  $ git unstage test.py

  实际上Git执行的是：

  $ git reset HEAD test.py

  配置一个git last，让其显示最后一次提交信息：

  $ git config --global alias.last 'log -1'

  这样，用git last就能显示最近一次的提交：

  $ git lastcommit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2Merge: bd6ae48 291bea8Author: Michael Liao <askxuefeng@gmail.com>Date:Thu Aug 22 22:49:22 2013 +0800merge & fix hello.py

  甚至还有人丧心病狂地把lg配置成了：

  git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

  来看看git lg的效果：
  

  为什么不早点告诉我？别激动，咱不是为了多记几个英文单词嘛！

  配置文件

  配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

  配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：

  $ cat .git/config [core]repositoryformatversion = 0filemode = truebare = falselogallrefupdates = trueignorecase = trueprecomposeunicode = true[remote "origin"]url = git@github.com:michaelliao/leagit.gitfetch = +refs/heads/*:refs/remotes/origin/*[branch "master"]remote = originmerge = refs/heads/master[alias]last = log -1

  别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。

  而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：

  $ cat .gitconfig[alias]co = checkoutci = commitbr = branchst = status[user]name = Your Nameemail = your@email.com

  配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。

  小结

  给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒。

git获取远程服务器的指定分支

昨天糗大了…进入新公司，公司服务器上有Online为线上版本，开发版本默认的为Master，本地clone的开发版为master,公司用的git 自动部署(puh后服务器自动更新了代码…这个有很多配置教程，这里就不赘述啦),
本地开发分支master,一般流程是 合并到online分支后，把online push到远程分支…这个是流程OK不说了
场景是这样的：
本地master
执行 checkout -b online后
git push origin online 发现权限不够…囧事发生了，我以为是账号权限受控…特意去问cto…
好吧，我这里操作是不对滴(按照以往的部署方式不能习惯性的用在新公司…警惕吧)
git pull 操作就可以从远程库中获取某个分支的更新，再与本地指定的分支进行自动merge(即使本地不存在这个分支)

完整格式是：

$ git pull <远程库名> <远程分支名>:<本地分支名>

比如，取回远程库中的online分支，与本地的online分支进行merge，要写成：

git pull origin online:online

如果是要与本地当前分支merge，则冒号后面的<本地分支名>可以不写

git pull origin online

通常，git会将本地库分支与远程分支之间建立一种追踪关系。比如，在git clone的时候，所有本地分支默认与远程库的同名分支建立追踪关系。也就是说，本地的master分支自动追踪origin/master分支。因此，如果当前处于本地online分支上，并且本地online分支与远程的online分支有追踪关系，那么远程的分支名可以省略：

比如，取回远程库中的online分支，与本地的online分支进行merge，要写成：

git pull origin 

其实，git pull 命令等同于先做了git fetch ，再做了git merge。即：

git fetch origin onlinegit checkout onlinegit merge origin/online

造成我的错误在于我本地使用checkout -b online 是创建的新onlne分支，而与服务器online根本不算是同一个分支，所以要从服务端拉取，切记吧

再次完整总结这次教训：

###git 拉取远程指定分支 pull本地不存在的分支

默认，如果git项目只有一个分支，就是master,我们当然可以在本地创建多个分支，并推送到远程git管理平台上，或者将远程git管理平台上的其他分支拉取到自己电脑上。

一、查看本地已有的分支

进入到项目根目录，打开命令行/终端，输入指令，将会显示该项目的本地的全部分支，其中、当前分支的前面有*号。

git branch

二、本地检出一个新的分支并推送到远程仓库

（一）.创建本地分支

git checkout -b 新分支名

执行该指令后，会在本地创建一个新分支，该分支是从当前分支上检出的，所以所有文件内容都和当前分支一模一样，这是正常的。创建成功后，将自动切换至新分支上。

比如我要创建一个名为dev1的新分支：

git checkout -b dev1

此时，再执行git branch查看当前本地所有分支，就会看到多了个分支：dev1.

（二）.推送本地分支到远程仓库

git push --set-upstream origin 分支名

例如，我要把上一步创建的本地dev1推送到远程仓库：

三、将远程git仓库里的指定分支拉取到本地（本地不存在的分支,今天的囧事就发生在这个环节）

当我想从远程仓库里拉取一条本地不存在的分支时：

git checkout -b 本地分支名 origin/远程分支名

这个将会自动创建一个新的本地分支，并与指定的远程分支关联起来。

例如远程仓库里有个分支dev2,我本地没有该分支，我要把dev2拉到我本地：

若成功，将会在本地创建新分支dev2,并自动切到dev2上。

如果出现提示：

fatal: Cannot update paths and switch to branch 'dev2' at the same time.Did you intend to checkout 'origin/dev2' which can not be resolved as commit?

表示拉取不成功。上面的我需要先执行

git fetch

然后再执行

git checkout -b 本地分支名 origin/远程分支名

即可。

其实这里就是我上面描述的，不用fetch,直接 git pull origin dev2:dev2 一个命令可以达到同等效果.

提示已经是最新的了…