一个完整的工作流程
1，从 GitHub 把中央仓库 clone 到本地（使用命令： git clone）
可以选择https和ssh两种形式，区别在于：
clone项目:使用ssh方式时，首先你必须是该项目的管理者或拥有者，并且需要配置个人的ssh key。下面会谈到如何生成并设置你的ssh key。而对于使用https方式来讲，就没有这些要求。
push:在使用ssh方式时，是不需要验证用户名和密码，如果你在配置ssh key时设置了密码，则需要验证密码。而对于使用https方式来讲，每次push都需要验证用户名和密码。
2，在本地进行修改，修改后提交
git add .
可以通过git status来查看状态
每个文件有 "changed / unstaged"（已修改）, "staged"（已修改并暂存）,
"commited"（已提交） 三种状态，以及一种特殊状态 "untracked"（未跟踪）
通过git commit提交
3，提交一次或多次之后，把本地提交 push 到中央仓库（git push）
在多人协作的项目中，通常需要在仓库创建分支，同时在本地也创建分支
创建 branch 的方式是 git branch 名称 或 git checkout -b 名称（创建后自动切换）；
切换的方式是 git checkout 名称；
git branch -d feature1 删除分支
出于安全考虑，没有被合并到 master 过的 branch 在删除时会失败（因为怕你误删掉「未完成」的 branch
这种情况如果你确认是要删除这个 branch （例如某个未完成的功能被团队确认永久毙掉了，不再做了），可以把 -d 改成 -D，小写换成大写，就能删除了。
1，同事 commit 代码到他的本地，并 push 到 GitHub 中央仓库
2，你把 GitHub 的新提交通过 pull 指令来取到你的本地
通过这个流程，你和同事就可以简单地合作了：你写了代码，commit，push 到 GitHub，然后他 pull 到他的本地；他再写代码，commit, push 到 GitHub，然后你再 pull 到你的本地。
写完所有的 commit 后，不用考虑中央仓库是否有新的提交，直接 push 就好
如果 push 失败，就用 pull 把本地仓库的提交和中央仓库的提交进行合并，然后再 push
push 是把当前的分支上传到远程仓库，并把这个 branch 的路径上的所有 commits 也一并上传。
push 的时候，如果当前分支是一个本地创建的分支，需要指定远程仓库名和分支名，用 git push origin branch_name 的格式，而不能只用 git push；或者可以通过 git config 修改 push.default 来改变 push 时的行为逻辑。
pull 的内部操作
pull 的实际操作其实是把远端仓库的内容用 fetch 取下来之后，用 merge 来合并。
git merge解决冲突
可以看到，Git 虽然没有帮你完成自动 merge，但它对文件还是做了一些工作：它把两个分支冲突的内容放在了一起，并用符号标记出了它们的边界以及它们的出处。上面图中表示，HEAD 中的内容是 移动硬盘（已买），而 feature1 中的内容则是 移动硬盘（不买了）。这两个改动 Git 不知道应该怎样合并，于是把它们放在一起，由你来决定。假设你决定保留 HEAD 的修改，那么只要删除掉 feature1 的修改，再把 Git 添加的那三行 <<< === >>> 辅助文字也删掉，保存文件退出，所谓的「解决掉冲突」就完成了。
通常，我们工作中说的merge代码的流程是
git checkout dev //切换到本地开发分支
git add .
git commit -m "描述"
git checkout master //切换到本地主分支
git pull //把远程仓库主分支代码拉下来，这样master分支就是最新的了
//或者可以
//git fench
//git merge
//存在冲突则进行修改
git checkout dev //切换开发分支
git merge master //将主分支代码合并到开发分支，这样，你的开发分支的代码就是最新的了
git push origin dev //把你的本地开发分支push到远程仓库的开发分支
如果你的项目上线了，你的分支上的代码就需要合到主分支上
git checkout master //切换到主分支
git merge dev//将开发分支合并到主分支，这样主分支就是最新的了
git push origin master //将本地主分支push到远程仓库，这样远程仓库的主分支就包含了本次开发的内容了
git其他命令
git log 可以查看历史记录
git log -p
查看历史中的多个 commit：git log
查看详细改动： git log -p
-p 是 --patch 的缩写，通过 -p 参数，你可以看到具体每个 commit 的改动细节
查看大致改动：git log --stat
如果你只想大致看一下改动内容，但并不想深入每一行的细节（例如你想回顾一下自己是在哪个 commit 中修改了 games.txt 文件），那么可以把选项换成 --stat
查看具体某个 commit：show
要看最新 commit ，直接输入 git show ；要看指定 commit ，输入 git show commit的引用或SHA-1
如果还要指定文件，在 git show 的最后加上文件名
查看暂存区和上一条 commit 的区别：git diff --staged（或 --cached）
使用 git diff --staged 可以显示暂存区和上一条提交之间的不同。换句话说，这条指令可以让你看到「如果你立即输入 git commit，你将会提交什么」
查看工作目录和暂存区的区别：git diff 不加选项参数
使用 git diff （不加选项参数）可以显示工作目录和暂存区之间的不同。换句话说，这条指令可以让你看到「如果你现在把所有文件都 add，你会向暂存区中增加哪些内容
查看工作目录和上一条 commit 的区别：git diff HEAD
使用 git diff HEAD 可以显示工作目录和上一条提交之间的不同，它是上面这二者的内容相加。换句话说，这条指令可以让你看到「如果你现在把所有文件都 add 然后 git commit，你将会提交什么」（不过需要注意，没有被 Git 记录在案的文件（即从来没有被 add 过 的文件，untracked files 并不会显示出来。为什么？因为对 Git 来说它并不存在啊）。
commit --amend 可以修复当前提交的错误。
使用方式：commit --amend
需要注意的有一点：commit --amend 并不是直接修改原 commit 的内容，而是生成一条新的 commit。
commit --amend 可以修复最新 commit 的错误，但如果是倒数第二个 commit 写错了，怎么办
现在再用 commit --amend 已经晚了，但可以用 rebase -i：
git rebase -i HEAD^^
说明：在 Git 中，有两个「偏移符号」： ^ 和 ~。
^ 的用法：在 commit 的后面加一个或多个 ^ 号，可以把 commit 往回偏移，偏移的数量是 ^ 的数量。例如：master^ 表示 master 指向的 commit 之前的那个 commit； HEAD^^ 表示 HEAD 所指向的 commit 往前数两个 commit。
~ 的用法：在 commit 的后面加上 ~ 号和一个数，可以把 commit 往回偏移，偏移的数量是 ~ 号后面的数。例如：HEAD~5 表示 HEAD 指向的 commit往前数 5 个 commit。
上面这行代码表示，把当前 commit （ HEAD 所指向的 commit） rebase 到 HEAD 之前 2 个的 commit 上
