对git的理解： 　　1、git跟踪的不是文件，而是修改，这就是git优秀而且快速的原因。 　　2、当你从远程克隆的时候，其实就是把git本地的master分支和远程的master分支对应起来了，远程仓库的默认名称是*origin*。

暂存区： 　　暂存区在git中是一个比较重要的概念，如果知道EntityFarmework的延迟加载的话，那么就好理解这个，因为暂存区和EF的延迟加载原理是一样的，都是把需要真正提交的数据暂时存储在一起，然后在执行提交命令的时候一次性全部提交。 　　暂存区就是用来存储执行git add命令后添加到git库的文件，暂存区的文件暂时没有提交到git的库里面，直到执行git commit命令才会真正的提交git add命令所添加的改变。

HEAD： 　　相当于c语言里面的指针，不过HEAD指向的是每一次提交的版本，比如你要回退到前一个版本，使用的是git reset --dead Head^，这个命令就是把HEAD指针指向了前一个版本。

管理修改： 　　每一次git commit的时候都是提交暂存区的文件，也就是提交了执行git add命令后的修改。假如做了一次修改，然后执行了git add命令，之后又对该文件做了修改，这时直接进行git commit就会发现，只有第一次的修改被提交到了git库里面，这是因为第一次修改完执行了git add命令，也就是把改变提交到了暂存区，而第二次修改没有执行git add，也就是没有提交到暂存区，这时执行git commit命令的时候只会把暂存区存储的第一次修改提交到git库里面。

远程git仓库： 　　上面所做的都是把文件修改、记录等存储在了本地的库里面，但是我们想要发挥分布式的功能、和其他人协作，或者是为了安全(硬盘挂了也不会丢失项目)，就需要将文件同步到云端，也就是保存在服务器上面，最著名的当然就是*github*了。但是鉴于国内的网络环境，比较推荐开源中国的*git@OSC*、github的寨版*gitcafe*。

分支： 　　分支的概念就是一个需要合理完成的项目，每个人都各干各的活，但是又怕代码没有完成提交后影响其他人的工作，更怕的是不提交就会丢失每天的工作进度，这在使用*SVN*等代码管理软件时是很常见的问题。为了解决这个两难的问题，git中就出现了分支。

　　如果你需要在一个完整的模块完成后再*push*到远程git库中，这时就可以创建一个属于自己的分支，然后在这个分支里面远程提交代码，这样既不影响别人的工作，也不怕丢失每天的工作进度。到最后完成时，可以直接将整个分支合并到总的远程库里面。

分支冲突： 　　如果我们在两个分支上分别修改并提交了同一个文件，那么在合并的时候就会发生冲突，使用git status命令可以查看冲突的文件是什么，然后打开冲突文件修改后再提交，然后可以使用git log --graph看到分支合并的具体情况。

分支管理策略： 　　在通常情况下，使用git合并分支使用的是*Fast forward*模式，也就是快速模式，在这种模式下合并后，如果删除了分支，就会丢失分支的信息(该分支合并、提交的信息，对出错后回退操作造成困难)。

　　可以强制禁用*Fast forward*模式，使用普通模式，这样git就会把合并当作一次普通的提交，也会留下commit id等信息，如果合并后需要回退版本就非常方便了。

　　git merge --no--ff -m "info" [branch name] --no--ff参数表示禁用*Fast forward*模式，把这次合并当作一次*commit*，所以使用-m参数填写了提交信息。

　　在实际开发中锋分支策略： 　　首先*master*分支应该是最稳定的，也就是每一个version发布的时候，才把其他的分支合并到*master*中。 　　 　　团队的成员可以在一个“次分支”*dev*上面提交，然后每个人都有自己的分支，在版本发布的时候，再把*dev*合并到*master*上。

bug分支： 　　使用场景：你的分支正在开发中，但是昨天提交的代码中有一个bug影响到了其他人的工作，你需要先停下手头的分支开发，去修复这个bug，然后再回来继续开发。有一个主要的问题就是，你当前手头的工作还没有完成不想提交，但是如果修改这个bug后提交的话，会连同所有的修改都提交上去。

　　git中的git stash命令可以将不需要提交的内容暂时隐藏起来，在提交的时候不会提交隐藏的内容。 　　首先执行git stash命令，将当前的工作区内容隐藏起来，然后确定需要修改的bug在哪个分支上面，就在哪个上面临时创建一个Bug分支。 假如在master分支上面，就先git chechout master回到master分支，然后git checkout -b [bug branch name]创建一个临时分支，修改Bug后提交到该临时分支，然后回到master分支合并删除该临时分支。这样就完成了临时修改bug的任务。

　　最后我们需要回到刚才手头的工作：可以使用git stutes命令查看，发现当前的工作区是干净的，因为bug已经修复提交，刚才的工作隐藏不见了，需要把刚才隐藏的内容找回来。

　　使用git stash list命令可以查看当前隐藏的工作区内容，需要恢复可以使用git stash apply命令，删除隐藏区内容使用git stash drop命令。也可以同时恢复并删除隐藏区，使用git stash pop命令，可以恢复的同时删除隐藏内容。 　　可以多次stash，这些stash的记录都在*stash list*中存储，可以恢复指定的stash，使用git stash apply stash@{0}命令，stash@{0}是执行git stash list命令显示的行首的参数。

feature分支： 　　每次添加一个新的功能最好就是添加一个新的分支，因为实验性质的代码，避免对主分支造成干扰。 　　如果要将一个没有合并的分支进行删除，需要进行强制删除，使用命令git branch -D [branch name]。

多人协作： 　　*push*命令就是将本地分支和远程库分支对应起来，不一定要什么内容都*push*上去，比如在你自己的分支上修改了一个bug，只需要合并到本地的分支里面，然后一同*push*，除非你需要把每个bug的信息提交到远程库。

标签管理： 　　发布一个版本时，我们通常先在版本库中打一个标签，这样就确定了当时打标签时的版本，如果有需要就能从这个标签获得完整的历史版本，所以标签相当于一个版本库的快照。git的标签其实指向的还是一个commit的指针(这和分支很像，但是分支是可以移动的，标签不能移动)。

　　标签默认是打在最新一次的提交上面的。所以如果想在指定的*commit*上面打标签，可以找到当时的*commit id*，使用命令git tag [tag name] [commit id]，这样就可以在指定的*commit*上面打上标签，也可以使用git tag -a [tag name] -m "标签说明"命令打上带有说明信息的标签。

　　使用git tag命令列出的tag列表不是按照时间顺序的，是按照字母排序的。

操作标签： 　　创建的标签都是打在本地的，所以可以安全的删除，如果需要把标签推送到远程库，推送某个标签可以使用命令git push origin [tag name]，推送所有的标签可以使用git push origin --tags。

　　删除标签可以使用git tag -d [tag name]命令，这个命令只是删除本地创建的标签，如果标签已经推送到了远程库，那么需要先删除本地标签，然后执行远程删除命令git tag push origin :refs/tags/[tag name]。 　　 以上知识点来自网络资料的学习，感谢廖雪峰老师的git教程，对我学习git帮助很大，也谢谢其他博主，分享让我们共同进步。