注意：
1、很多分支图中的箭头表示的是该分支的父分支，也是用来表示上一层的分支。
工作流程：
git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：
去自己的工作分支
$ git checkout work
工作
….开始修改文件代码
提交工作分支的修改
$ git commit -a
回到主分支
$ git checkout master
获取远程最新的修改，此时不会产生冲突
$ git pull
回到工作分支
$ git checkout work
用rebase合并主干的修改，如果有冲突在此时解决
$ git rebase master （这一步可以看到都有的还有两者冲突的地方，如果小分支上有其他东西，主分支没有，则这一步不会显示小分支上的东西）大多数时候，使用 git pull –rebase 是为了使提交线图更好看，因为他会将你的分支上的commit移走，使得提交线路图没有，从而方便 code review，看起来就更加的简洁明朗。
回到主分支
$ git checkout master
合并工作分支的修改，此时不会产生冲突。
$ git merge work
提交到远程主干
$ git push
（本地的160421feature分支利用命令git push origin 160421feature后，将提交的信息给了远程160421feature分支（如果分支不存在，则会自动创建这个远程分支），然后要手动的提交一个 pull request，然后master端进行合并就可以了，否则没有效果。
这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。
关于协同合作：
1、fork别人了代码之后，clone到本地，
2、然后增加一个分支，提交之后，在使用简单的git push将feature分支推送到了她自己的Github仓库上（不是官方的仓库）：
git push origin some-branch
3、用自己的Github账号在自己的远程仓库上对刚提交的分支创建一个pull request，这样项目维护者就看到了，审核通过了就点击Merge Pull Request按钮来通过这个pull request，将Mary的feature分支并入他的master分支
误删除一个文件的时候可以用指令来返回救回 自己的文件，bac.c这个文件被删除了，
命令行：
git reset HEAD bac.c
（将文件返回到前一个状态）
git checkout bac.c 恢复这个文件
git 目录中经常会出现一些[ +1 ~1 ~0] 这样形式的东西，
第一个数字表示：增加的文件的个数。
第二个数字代表修改的文件个数。
第三个数字表示已经删除的文件个数。
如果出现第四个数字，且数字前有感叹号，这就表示：有冲突，数字代表冲突的文件个数。
设置一些过滤文件的通用副：
*.class
.classpath
.gitignore
.myhibernatedata
.mymetadata
.paoject
github 中的同步是将本地的 master同步到远程仓库的master，但是如果你没有commit，则不会同步到远程master，没有commit表示没有提交修改，github也没有更新你的修改操作，本地的master自然也就没有修改，所以这个时候同步没有任何问题，自然同步都不会有新的更新到远程（做过实验）。
建议在本地建立一个分支，在本地的分支上修改代码，然后commit（提交到本地的分支上），这样你的分支代码就有一个形成了一个新的版本，但是并没有在你本地的master上更新，也没有更新远程的master。
此时：
1.利用本地的分支，将更新提交到远程master，也就是提交合并，但这是你本地的master也没有更新。
2. 切换到你本地的master，将远程的master更新到本地的master，将本地master与本地分支对比修改的代码，没有冲突，没有问题之后，将本地分支和本地master 合并 到本地master，最后向远程master提交合并请求 或者 同步到远程的master。
关于分支的几点问题：
- 1.分支上的代码是最新的，并且已经commit了，如果此时你将 HEAD （指针）指向了 本地master，因为本地master没有你刚刚修改的东西，这时候你会发现你的myeclipse上的代码回到了你没修改的状态去了，但是如果你这时在切换到分支，你的代码就有恢复了。这也是github的强大之处，你可以随便创建分支修改、调试修复bug、增加、删除，然后不行就切换到其他分支，删除这个分支。
- 2.github只记住你的修改操作，不会记住文件，通过指令：git status，可以看到你的项目的一些状态，git log ,可以看到你commit的操作。
- 3. 如果你修改了代码或者文件，没有提交到本地该分支，则这个时候不可以切换到其他分支去，只有提交了才可以切换，但是 如果你只是增加了一个文件，并写上一些内容，这个时候是可以切换到其他分支的，因为程序默认是没有这个文件的。
git branch <branch> // 创建一个分支
git branch -d <branch> // 删除一个分支
git branch -D <branch> //强行删除一个未合并更改的分支，永远删除某一个分支的所有提交，就可以用这个命令
git branch -m <branch> // 给当前分支修改名称为<branch>Git执行 三路合并 。三路合并使用一个专门的提交来合并两个分支的历史。这个术语取自这样一个事实，Git使用 三个 提交来生成合并提交：两个分支顶端和它们共同的祖先。
如果你写错了代码，并且commit了，那么你想撤销commit，可以利用命令：git reset –hard HEAD^ 。但是这是回到你的上一个版本，并不会保留你commit之前到上一个版本这之间的所有修改操作，也就意味着你必须重新写代码。
Untracked---有修改但是没有git add操作，它的状态是Untracked。
staged(暂存区)---将有修改的文件进行git add 操作之后，文件就在 staged（ 暂存区）了。
discard changes---放弃更改。
git remote -v 可以查看当前项目与那些远程仓库有url 远程连接
git remote add john http://dev.example.com/john.git 添加同事的账号
————————————————————创建本地的仓库——————————————————————
在本地写代码的时候必须做测试，测试功能，如果自己改代码之后还要改回来，如果遗漏了 一步就会造成自己忽略掉的错误，用github可以帮我很好的进行版本控制，
建议本地的仓库路径是———-G:\GitHub
- (1)如果要自己创建一个文件并初始化为github管理，执行以下命令
$ mkdir learngit 创建一个文件夹
$ cd learngit （可省略）
$ pwd （可省略）用于显示当前目录
$ git init 把这个目录变成Git可以管理的仓库- (2)将已经有的项目导入github的目录中，也就是 G:\GitHub目录中
使用git init 把这个目录编程git可以管理的仓库
以上两步做完了还有一件重要的事情要做，那就是创建分支，就是利用分支这种套路来改程序的，最好创建多个分支，主分支不要改动太大，一个分支A用来写代码，一个分支B用来做测试，测试好了A的代码，就吧A提交到主分支上去。
创建分支：$ git branch test
切换分支：$ git checkout test或者利用一个命令就可以吧上面两句命令一同处理掉 ：
$git checkout -b test
一些基本处理命令：
git status 查看状态，列出已缓存、未缓存、未追踪的文件。
git add 添加文件到缓存区
git commit -m "<在此处添加提交理由或者改动理由>" 提交文件到正式工作区中- git status 允许你查看工作目录和缓存区，而git log只作用于提交的项目历史。
- git log 相关命令如下
git log ---使用默认格式显示完整地项目历史。如果输出超过一屏，你可以用空格键来滚动，按q退出。
git log -n <limit> ---用<limit>限制提交的数量。比如git log -n 3只会显示3个提交。
git log --oneline ---将每个提交压缩到一行。当你需要查看项目历史的上层情况时这会很有用。
git log --stat ---除了git log信息之外，包含哪些文件被更改了，以及每个文件相对的增删行数。
git log -p ---显示代表每个提交的一堆信息。显示每个提交全部的差异(diff)，这也是项目历史中最详细的视图。
git log --author="<pattern>" ---搜索特定作者的提交。<pattern>可以是字符串或正则表达式。
git log --grep="<pattern>" ---搜索提交信息匹配特定<pattern>的提交。<pattern>可以是字符串或正则表达式。
git log <since>..<until> ---只显示发生在<since>和<until>之间的提交。两个参数可以是提交ID、分支名、HEAD或是任何一种引用。
git log <file> ---只显示包含特定文件的提交。查找特定文件的历史这样做会很方便。
git log --graph --decorate --oneline ---还有一些有用的选项。--graph标记会绘制一幅字符组成的图形，左边是提交，右边是提交信息。--decorate标记会加上提交所在的分支名称和标签。--oneline标记将提交信息显示在同一行，一目了然。
上面提供了git log很多的栗子，但请记住，你可以将很多选项
用在同一个命令中：
git log --author="John Smith" -p hello.py ---这个命令会显示John Smith作者对hello.py文件所做的所有更改的
差异比较(diff)。
..句法是比较分支很有用的工具。
下面的栗子显示了在some-feature分支而不在master分支的所有
提交的概览。
git log --oneline master..some-feature
关于checkout 命令详解———-检查提交———
git log –oneline // 查看当前的所有提交
git checkout a1e2fb5 // 查看某一个提交的当时所有文件的状态，在此状态你可以测试、修改，但是你的修改不会更新到仓库里。
git checkout master //退出此commit状态,切换到master状态
———检查提交中的某一个文件——-
git log –oneline // 查看当前的所有提交
git checkout a1e2fb5 hello.py // 查看某一个提交的当时某一个文件的状态，在此状态你可以测试、修改，但是你的修改会更新到仓库里。
git checkout HEAD hello.py //如果你不想保留修改的旧的版本文件，你可以用命令检出到最近文件版本，
git 退出 git log：经常输入 git log 后， 即使按ctrl+c (z)都无法完全退出，后来google了一下，原来要输入q。
——————————-常见工作流流程—————————–
1、中心化的工作流
只需要一个master分支，不需要其他分支，所有的提交都到了master分支上，所以在各个开发者提交他们自己的代码之前，要先fetch下中央仓库的代码，在他们上rebase自己的更改。
git pull --rebase origin master
--rebase选项告诉Git，在同步了中央仓库的修改之后，将Mary所有的提交移到master分支的顶端
如果发现了冲突，合并提交会终止，利用git status就可以看到那些文件发生了冲突，
接下来就是修改冲突，git add 来添加这些被你修改的文件，
然后执行 git rebase --continue ---继续执行合并提交操作，
最后 git push origin master.2、基于功能分支的工作流
创建本地分支，对分支进行修改提交，feature分支可以（也应该）被推送到中央仓库，这样master上也会有多个feature分支，最后通过 pull request来请求合并到master。
而不是直接将分支推送到master上，这样就给了其他开发者审核代码的机会，不仅可以审查还可以讨论代码，
git push -u origin marys-feature这个命令将marys-feature推送到中央仓库(origin)，-u标记将它添加为远程跟踪的分支。在设置完跟踪的分支之后，Mary调用不带任何参数的git push来推送她的功能。
然后在他自己的Git界面上发起了一个pull request，请求将marys-feature合并进master。
当大家都觉得这个功能代码做的很出色的时候，一致认可可以将该分支合并到主分支master上的时候，我们就需要以下操作：
git checkout master
git pull
git pull origin marys-feature
git push3、Gitflow工作流
- 该工作流围绕项目发布定义了一个严格的分支模型。和功能分支工作流相比，这种工作流没有增加任何新的概念或命令。它给不同的分支指定了特定的角色，定义它们应该如何、什么时候交流。除了功能分支之外，它还为准备发布、维护发布、记录发布分别使用了单独的分支。当然，你还能享受到功能分支工作流带来的所有好处：pull request、隔离实验和更高效的协作。
- 开发者将分支推送到远程仓库，不同的是项目的分支结构变化了，使用两个分支来记录项目历史，master分支存储官方发布历史，develop分支用来整合功能分支，这还可以在master分支上给所有提交打上版本号标签，
- 所有开发者将develop分支作为父分支，提交功能分支到develop分支，与develop分支进行交互，功能分支加上develop分支就是我们之前所说的功能分支工作流。但是，Gitflow工作流不止于此。
步骤：
- 首先在本地的master分支上创建一个空的develop分支，将其推送到服务器上：
git branch develop
git push -u origin develop
develop分支其实是包含master的所有内容，所有历史。
然后其他的开发者对develop分支克隆，并且在本地创建一个分支来追踪develop分支：
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop 创建本地的特征分支：
git checkout -b some-feature develop
当完成了功能分支，他提交到develop分支，最好发起一个pull request，
采纳这个功能分支：
git checkout master
git merge release-0.1
git push 或者下面两句话
git tag -a 0.1 -m "Initial public release" master
git push --tags
git checkout develop
git merge release-0.1
git push
git branch -d release-0.14、Fork工作流
Fork工作流和教程中讨论的其它工作流截然不同。与其使用唯一的服务端仓库作为”中央“代码库，它给予 每个 开发者一个服务端仓库。也就是说每个贡献者都有两个Git仓库，而不是一个：一个私有的本地仓库和一个公开的服务端仓库。
Fork工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送到他们 自己的 服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以接受任何开发者的提交，却不需要给他们中央仓库的权限。
结论是，这种分布式的工作流为大型、组织性强的团队（包括不可信的第三方）提供了安全的协作方式。它同时也是开源项目理想的工作流。
fork工作流会克隆开源项目到自己的私人服务器上，然后自己从自己私人服务器上克隆到本地，并进行修改，然后提交合并到自己私人服务器，通过pull request 告知项目维护者，我要将更新的操作添加到官方项目中，维护者会去检测你的代码，没有问题就会合并到官方项目中。
因为主代码库已经取得了新的进展，其他开发者应该和官方仓库同步：
git pull upstream master
5、远程分支的操作
当你的代码不是最新的时候，需要用 git fetch origin 从远程服务器上获取数据.git fetch 命令会更新 remote 索引，但不会覆盖你本地的分支操作。
也可以用 $ git push origin serverfix(分支名字) 来将本地操作同步到远程仓库
6、跟踪分支
从远程分支 checkout 出来的本地分支，称为 跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。
git checkout -b serverfix_1 origin/serverfix从远程分支serverfix中获取一个分支serverfix_1，这两者可以名字一样，因为涉及到另一个问题，名字一样，本地的跟踪分支可以直接利用 git push，来更新内容到远程分支上，如果名字不一样就必须使用：git push origin HEAD:serverfix 更新代码到远程serverfix分支。
同样支持 改名：git checkout -b sf origin/serverfix 将本地的serverfix分支改名为 sf。
同样利用 git push origin :serverfix 将服务器上的远程分支serverfix删除。远程主页上也可以删除。不过建议在其他分支上删除远程分支，不要在跟踪分支上删除远程分支。
6、冲突解决
如果有冲突发生，最简单的方法就是修改冲突，然后再次add 和commit，这样就手动修改冲突，
如果大量的工作发生，就很恐怖，所以，需要撤销一个合并操作，思考。
你应该始终牢记，你可以在任何时间执行撤销操作，并返回到你开始合并之前的状态。要对自己有信心，你不会破坏项目中的任何东西。只要在命令行界面中键入 “git merge –abort” 命令，你的合并操作就会被安全的撤销。
当你解决完冲突，并且在合并完成后发现一个错误，你仍然还是有机会来简单地撤销它（前提是没有commit）。你只须要键入 “git reset –hard ” 命令，系统就会回滚到那个合并开始前的状态，然后重新开始吧！
7、add操作之后，如何回退
万一你不小心git add file(add File文件了，哪怕文件置灰，也是能提交的)了，怎么办，不用急
两种思路：
- 用git命令来操作
使用git 命令如下：
git rm --cached file_path
git commit -m '移除测试文件'
删除本地缓存，但是不删除文件。测试的文件在处于置灰状态就不能提交了！或者 git reset HEAD 将文件回退
直接手动重新修改，再add操作。
手动重新编辑，因为并没有commit，所以可以重新编辑再提交。
如果一个文件不需要提交，当然也不需要commit，可以采用第一种方法。
8、commit操作后撤销
撤销操作
- 提交一份快照
git commit -m “Make some changes that will be undone”
- 撤销刚刚的提交
git revert HEAD // 将缓存区的文件撤销掉到非缓存区
git reset命令在准备缓存快照时经常被用到，可以单独撤销一个文件的状态，也可以撤销所有文件的缓存区。
9、git status的相关文件状态说明
Untracked files： 表示未跟踪的文件，也表示这些文件不在之前的状态里，是新建立的文件，有可能这些文件是你创建的，也有可能是运行程序产生的.class文件，这些文件要被你忽略。 通过git add 操作就可以来添加跟踪。
Changes not staged for commit：表示文件被修改，但是没有add，没有添加到暂存区。要暂存这次更新，需要运行 git add 命令。
Changes to be committed: 等待提交，目前已经在暂存区了。
注意：可能存在同样一个文件同时是在暂存区和 等待提交区。这是因为你把文件添加到暂存区后没有commit，但是有同样修改了这个文件。
- deleted: 有些文件的状态是deleted，这表明这些个文件是被删除的文件，一般这些删除的文件是处于Changes not staged for commit 。可以使用 git add/rm 等操作将这些文件添加到暂存区。然后最后commit的时候，该文件就不再纳入版本管理了。
10、怎样从之前的版本中创建分支？
这个问题也可以称为：git基于历史commit创建分支
- 利用 git log 来获取历史commit 操作，
- 利用 git checkout -b 从历史中某个commit中创建一个新的分支，这条命令中： 表示分支名， 表示 commit 的 序列号，每次commit都会自动生成。
- 在新分支上开发，后续继续合并或者回退
11、关于 Your branch and ‘origin/master’ have diverged, and have 1 and 1 different commits each, respectively.
首先解释一下：
- 这里的第一个 数字 1 表示本地master 比 origin/master 多了1个patch。
- 第二个数字 1 表示表示本地master 比 origin/master 少了1个 patch。
12、从远程分支上 clone 下代码
使用命令：git clone -b v2.8.1 https://git.oschina.net/oschina/android-app.git
-b表示要从分支下载，v2.8.1就是具体的某个分支的名称，https://git.oschina.net/oschina/android-app.git这是app源码的git仓库地址。
13、将本地项目上传到git目录中
- 初始化项目 git init
- 将项目文件add, git add <文件名>
- 提交，git commit -m “<说明>”
- 跟远程git关联 git remote add origin
- 上传项目到远程git git push -u origin master
14、在本地新建一个与远程的dev版本相同(被合并的版本)的dev分支
- 将master分支弄下来
git clone [ssh:XXXX.git] - 将远程分支弄下来，弄到本地
git checkout -b dev origin/dev - 返回到master版本
git checkout master- 把本地的dev合并到master.
git merge dev
- 把本地的master同步到远程
git push origin master参考博客
参考的博客较多，长期积累的，也找不到博客链接了，总之，感谢各位大佬的分享。
————————————————————————END————————————————————————–