git & GitHub
Linux上安装Git
首先，你可以试着输入git，看看系统有没有安装Git：
$ git The program 'git' is currently not installed. You can install it by typing: sudo apt-get install git
像上面的命令，有很多Linux会友好地告诉你Git没有安装，还会告诉你如何安装Git。
如果你碰巧用Debian或Ubuntu Linux，通过一条sudo apt-get install git就可以直接完成Git的安装，非常简单。
bash基本操作：
1）、cd : 改变目录。 2）、cd . . 回退到上一个目录，直接cd进入默认目录 3）、pwd : 显示当前所在的目录路径。 4）、ls(ll): 都是列出当前目录中的所有文件，只不过ll(两个ll)列出的内容更为详细。 5）、touch : 新建一个文件 如 touch index.js 就会在当前目录下新建一个index.js文件。 6）、rm: 删除一个文件, rm index.js 就会把index.js文件删除。 7）、mkdir: 新建一个目录,就是新建一个文件夹。 8）、rm -r : 删除一个文件夹, rm -r src 删除src目录， 好像不能用通配符。 9）、mv 移动文件, mv index.html src index.html 是我们要移动的文件, src 是目标文件夹,当然, 这样写,必须保证文件和目标文件夹在同一目录下。 10）、reset 重新初始化终端/清屏。 11）、clear 清屏。 12）、history 查看命令历史。 13）、help 帮助。 14）、exit 退出。 15）、#表示注释
版本库创建
创建一个版本库非常简单，首先，选择一个合适的地方，创建一个空目录：
1.切换目录（创建空目录）
2.通过 git init 命令把当前目录变成git可以管理的仓库（初始化一个git仓库）
用ls -ah命令可查看该目录下生成一个.git目录，.git文件不能随意改动。
$ mkdir git_trainning $ cd git_trainning/ $ git init Initialized empty Git repository in /Users/alex/git_trainning/.git/
编写一个first_git_file.txt文件，内容如下：
$ vim first_git_file.txt
first time using git, excited!
第一次用git哈哈
注：一定要放到git_trainning目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件
把一个文件放到Git仓库（本地仓库）只需要两步：
第一步，用命令git add告诉Git，把文件添加到仓库：
$ git add first_git_file.txt
第二步，用命令git commit告诉Git，把文件提交到仓库：
1 $ git commit -m "commit my first git file" 2 3 [master (root-commit) 621e6e4] commit my first git file 4 Committer: Alex Li <alex@Alexs-MacBook-Pro.local> 5 Your name and email address were configured automatically based 6 on your username and hostname. Please check that they are accurate. 7 You can suppress this message by setting them explicitly. Run the 8 following command and follow the instructions in your editor to edit 9 your configuration file: 10 11 git config --global --edit 12 13 After doing this, you may fix the identity used for this commit with: 14 15 git commit --amend --reset-author 16 17 1 file changed, 2 insertions(+) 18 create mode 100644 first_git_file.txt
注：-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录
同一个用户第一次往git库里提交代码时，你需要告诉git你是谁，这样git就会纪录下来是谁改的代码，其实就是为了日后查询方便，你只需要提供一个名字和邮件地址就可以，你也可以通过git config --global --edit修改
git config --global user.email nan@example.com #创建email git config --global user.name nan #创建用户名
git基本指令
git init # 初始化git git add file.py # 把代码放入git暂存区 git commit -m “” # 把代码从暂存区存入仓库 git status # 查看当前的代码修改状态 git checkout --file # 撤销在工作区对文件的修改，恢复到修改前 git reset --hard HEAD^ # 回滚到上一次 git reset --hard 343sd23 # 回滚到指定的版本 git dff 文件名 # 查看不同（哪做了修改） git rm file # 本地删除 git log # 查看历史记录 git log --pretty=oneline # 一行显示数据 git relog # 记录所有的操作记录
远程仓库
1.自己搭建一台运行Git的服务器
2.注册GitHub，免费获得Github远程仓库
2.1两种方式将本地仓库内容推送到GitHub远程仓库（已创建仓库）：
（1）.HTTPS方式：获取远程仓库https链接：https://github.com/Alnan/git_first_test.git
将数据提交到本地仓库后，执行下面代码：
git remote add origin https://github.com/Alnan/git_first_test.git # 首次提交需要，再次提交则不用此行代码（每新建仓库都是首次提交） git push -u origin master # 将本地仓库内容提交到远程仓库，第二次提交可以不用带参数-u # test Administrator@U1R2QLM1APQJA1N MINGW32 /g/Git/git_test (master) $ git push origin master Counting objects: 3, done. #提交成功显示内容 Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 287 bytes | 287.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/Alnan/git_first_test.git 0ce5d73..670eca7 master -> master
（2）.SSH加密方式：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
$ ssh-keygen -t rsa -C "youremail@example.com"
你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容。点“Add Key”，你就应该看到已经添加的Key。
这样就可以以SSH加密方式进行仓库内容推送了
现在，我们根据GitHub的提示，在本地已有的git_trainning仓库下运行命令：
$ git remote add origin git@github.com:triaquae/oldboy_website.git ＃添加远程仓库 $ git push -u origin master #推到远程 The authenticity of host 'github.com (192.30.253.113)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no)? yes #第一次推会出现，写yes Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts. Counting objects: 20, done. Delta compression using up to 8 threads. Compressing objects: 100% (14/14), done. Writing objects: 100% (20/20), 1.76 KiB | 0 bytes/s, done. Total 20 (delta 4), reused 0 (delta 0) remote: Resolving deltas: 100% (4/4), done. To git@github.com:triaquae/oldboy_website.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
请千万注意，把上面的triaquae替换成你自己的GitHub账户名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
2.2.从远程库克隆到本地库：
我们讲了先有本地库，后有远程库的时候，如何关联远程库。
现在，假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。
首先，登陆GitHub，创建一个新的仓库，名字叫gitskills：
我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件：
现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：
在本地找一个你想存放这个远程仓库的目录（git下的目录），然后在本地命令行用git clone 命令来克隆这个远程库
$ git clone git@github.com:triaquae/gitskills.git # 需本地Git目录下 Cloning into 'gitskills'... Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts. remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. Checking connectivity... done. $ cd gitskills/ #进入刚clone下来的目录 $ ls README.md
分支
相关指令操作：
git pull # 从远程更新代码（克隆远程代码到本地，需先更新远程代码） git push # 把本地代码推送到远程 git checkout -b dev（分支名） # 在master创建并切换到分支，相当于下面两条指令 git branch dev # 创建分支 git checkout dev # 切换分支，注：分支名换成文件名表示撤销在工作区对文件的修改 git branch # 查看当前分支 git merge dev # 在maste分支上合并其他分支 git branch -d dev # 删除分支 git stash # 把当前工作环境临时保存（非仓库） git stash lish # 查看所有临时保存的工作环境列表 git stash apply # 恢复之前保存的临时工作（但不删除临时保存的环境备份，需用git stash drop 删除） git stash drop # 删除当前临时保存的环境备份 git stash pop # 恢复并删除临时保存的环境备份 git remote # 查看远程库的信息， 加参数-v，查看更详细信息git checkout -b dev origin/dev #要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支
git branch --set-upstream branch-name origin/branch-name #如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用此命令
实例：
首先，我们创建dev分支，然后切换到dev分支：
$ git checkout -b dev Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev $ git checkout dev Switched to branch 'dev'
然后，用git branch命令查看当前分支：
$ git branch * dev master
git branch命令会列出所有分支，当前分支前面会标一个*号。
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：
Creating a new branch is quick.
然后提交：
$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+)
现在，dev分支的工作完成，我们就可以切换回master分支：
$ git checkout master Switched to branch 'master'
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的工作成果合并到master分支上：
$ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
合并完成后，就可以放心地删除dev分支了：
$ git branch -d dev Deleted branch dev (was fec145a).
删除后，查看branch，就只剩下master分支了：
$ git branch * master
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
解决冲突
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。
准备新的feature1分支，继续我们的新分支开发：
$ git checkout -b feature1 Switched to a new branch 'feature1'
修改readme.txt最后一行，改为：
added this line from branch feature 1
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "add feature"
[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文件的最后一行改为：
added this line from master
提交：
$ git add readme.txt
$ git commit -m "master update"
[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 study repo Creating a new branch is quick. <<<<<<< HEAD added this line from master ======= added this line from branch feature 1 >>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：
#git study repo Creating a new branch is quick. added this line from master added this line from branch feature 1
再提交
$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed
现在，master分支和feature1分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline * feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict |\ | * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch * | 743ccee30f3d74f1993f17e7312032b7399b1306 from master |/ * edfbc29982927236596539e0f1971b0575f803c0 branch test * 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，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: 6224937 add merge HEAD is now at 6224937 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. $ 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 cc17032] 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 2 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(-) $ git branch -d issue-101 Deleted branch issue-101 (was cc17032).
太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！
$ git checkout dev Switched to branch 'dev' $ git status # On branch dev nothing to commit (working directory clean)
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 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} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)
再用git stash list查看，就看不到任何stash内容了：
$ git stash list
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote：
$ git remote origin
或者，用git remote -v显示更详细的信息：
$ git remote -v origin git@github.com:triaquae/gitskills.git (fetch) origin git@github.com:triaquae/gitskills.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
* 推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
-
master分支是主分支，因此要时刻与远程同步； -
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； -
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
-
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
* 抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。
现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：
$ git clone git@github.com:triaquae/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 16, done. remote: Compressing objects: 100% (7/7), done. remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0 Receiving objects: 100% (16/16), done. Checking connectivity... done.
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch * master
现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
$ git checkout -b dev origin/dev
现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：
$ git add . $ git commit -m "small updates" [dev f1b762e] small updates 2 files changed, 5 insertions(+), 1 deletion(-) Alexs-MacBook-Pro:gitskills alex$ git push origin dev Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 438 bytes | 0 bytes/s, done. Total 4 (delta 0), reused 0 (delta 0) To git@github.com:triaquae/gitskills.git 33ec6b4..f1b762e dev -> dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送:
$ git add . $ git commit -m "add Dog class" [dev 7e7b1bf] add Dog class 2 files changed, 7 insertions(+) $ git push origin dev To git@github.com:triaquae/gitskills.git ! [rejected] dev -> dev (fetch first) error: failed to push some refs to 'git@github.com:triaquae/gitskills.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. #提示你了，先把远程最新的拉下来再提交你的 hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推
$ git pull
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com:triaquae/gitskills
33ec6b4..f1b762e dev -> origin/dev
There 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 dev Branch dev set up to track remote branch dev from origin.
再pull：
$ git pull Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Auto-merging branch_test.md CONFLICT (content): Merge conflict in branch_test.md Automatic merge failed; fix conflicts and then commit the result.
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：
$ git add . $ git commit -m "merge & fix hello.py" [dev 93e28e3] merge & fix hello.py $ git push origin dev Counting objects: 8, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (8/8), 819 bytes | 0 bytes/s, done. Total 8 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), done. To git@github.com:triaquae/gitskills.git f1b762e..93e28e3 dev -> 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。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
忽略特殊文件.gitignore
有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
- 忽略操作系统自动生成的文件，比如缩略图等；
- 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的
.class文件； - 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
举个例子：
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：
# Windows: Thumbs.db ehthumbs.db Desktop.ini
然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：
# Python: *.py[cod] *.so *.egg *.egg-info dist build
加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：
# Windows: Thumbs.db ehthumbs.db Desktop.ini # Python: *.py[cod] *.so *.egg *.egg-info dist build # My configurations: db.ini deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：
$ git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -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行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
小结
-
忽略某些文件时，需要编写
.gitignore； -
.gitignore文件本身要放到
git命令汇总（转载）
扫一扫
259
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
