Git作为最流行的代码版本控制工具，基本上已经成为了程序员的一个标配技能。无论使用GitHub，GitLib，Gitee等进行代码托管，均基于Git。下面聊一聊开发人员必会的几个Git技巧和团队协作的一些Git工作流。1 Git 常用的超级实用命令1.1 与仓库相关的操作克隆代码仓库到本地，开发必用git clone
查看本地仓库配置了那些对应的远程仓库。git remote -v
添加远程仓库git remote add name >
更新远程仓库地址git remote set -url --push
拉取远程仓库git pull
推送本地仓库到远程仓库，默认是当前所在branchgit push
1.2 分支的创建切换等相关操作查看本地分支/所有分支git branch / git branch -a
查看远程分支git branch -r
创建本地分支git branch
本地创建分支并和远程分支关联，再切换到该分支。git checkout -b /
git branch -b /
根据远程分支创建本地分支，但是不会切换到新分支，需要手动checkoutgit fetch :
创建新分支并立刻切换到改分支git checkout -b
创建远程分支：git push origin
删除远程分支git push origin:heads/
也可以push一个空的本地分支，那么也将删除远程分支
修改分支名git branch -m
git branch -m (修改当前BranchName)
1.3 Tag相关查看Taggit tag
创建Taggit tag
删除Taggit tag -d
查看远程Taggit tag -r
push Tag到远程仓库git push origin
删除远程Taggit push origin:refs/tags/
1.4 git 提交相关先add 然后在提交，不过add大多时候利用开发工具来做比较方便。git add newfile.txt
git commit -m "the commit message"
reset相关的命令可以回滚刚才的add或者提交，重设当前分支git reset [--hard|soft|mixed] [或HEAD]
最后一个参数默认为HEAD，HEAD~2表示上上一个版本，也可以是某一个commit id处。常用的三个参数hard/mixed/spft--hard 将之前的提交全部删除stage区清空，--mixed 将之前的提交删除，但是将改动移动到stage区（也就是index中）。--soft 提交不改变变，将HEAD指向某commit id，有点像checkout1.5 合并合并其他分支到当前的分支git merge
合并分支fixes和enhancements在当前分支的顶部git merge fixes enhancements
将一个commit 合并到当前分支git cherry-pick
合并几个连续的commitgit rebase -i 4e08572
下面给出一组Rebase 的详细示例（1）windows 下，输入上述命令之后, 输入i 进入编辑窗口，更改rebase策略。详细解释都有提示，只需根据提示输入即可。（2）选好rebase策略之后按Esc推出 输入"：x" 执行 刚才的rebase操作，然后会看到修改提交的信息界面（3）修改提交信息，按Esc退出，并输入 "：x" 执行rebase操作然后看到rebase成功e以上就是一个简单的rebase操作。1.6 log & show查看最近的5次提交，按Q就直接退出。git log -5
使用ASCII图形表示分支合并历史git log --graph
显示最近5次提交的详细内容git show -5
2 Git Work Flow2.1 Centralized WorkflowCentralized WorkFlow 这种模式对比熟悉SVN的开发人员比较容易适应。在Git 远程仓库有一个主分支，开发人员也在自己的本地克隆了一个完全一样的分支，开发人员可以在本地的分支上随意的进行代码编写，测试。当完成当前开发工作之后，可以直接push到远程主分支上。就算是有冲突也可以快速的解决。中心仓库式工作流对于小型开发团队比较适用，人员少，改动也就相对比较少，出现冲突的几率也要少很多。就算是有冲突，合并也不会有太大问题。显然这种工作方式却不适合大型团队，几个开发组同时开发维护一个项目，这样代码会非常混乱，每个人的提交都会影响其他组开发的工作。如果再有不同组的开发任务上线时间点不一样，那么就是一场灾难。2.2 Feature Branch Workflow基于Feature Branch WorkFlow 的Git工作流，其基于一个中心仓库，主分支（也可以是其他的生产代码分支）代表了项目历史。每次有新的开发任务的时候，基于主分支新创建一个Feature分支，和当前任务相关的代码都提交的这个Feature分支。当开发工作进行到一定阶段，就可以提一个Pull Request代主分支，这个时候就可以让同事去Review自己的代码了。此时Review阶段可能会有一些小问题，或者同事给出了更好的建议，我们都可以针对性的修改代码。最后让测试等工作都完成之后，就可以将Feature 分支合并到主分支上。最终测试完成之后就可以部署到生产上面。之后Feature分支可以视情况删除，或者保留一段时间之后再删除。2.3 GitFlow WorkFlowGitFlow WorkFlow是一种比较经典的工作模式。其主要有如下的一些分支协作。Main/Master Branch （主分支）：维护着项目的历史记录，会记录每一次上线的标签，并且可以看到每一次上线的一些新特性等。Develop Branch （开发分支）：基于主分支，主要是为了下一次上线所使用的开发分支，可以接受Feature分支的Pull Request。当所有的新特性都已经合并完毕，那么就创建。Release Branch （部署分支）：当开发分支已经合并了足够的特性分支代码之后，会创建一个Release分支。此时Release分支不会接受任何Feature分支的Pull Request，仅接受一些Bug fix的Pull Request。Release分支部署上线之后，测试全部通过后会将代码合并到Develop 分支和主分支。Feature Branch （特性分支）：一般会基于开发分支创建出一条针对某个功能的分支，开发人员会基于这条分支进行开发和单元测试的工作，当本Feature开发完成之后。会将代码合并到Develop分支上，之后可以选择适时删除次分支。Hotfix Branch （修补分支）：针对与线上出现的紧急问题，从主分支，也就是上一次上线的标签出创建一个Hotfix 分支。当问题解决之后，可能会有一次紧急的上线来解决之前发现的问题。当问题解决之后，会将代码合并到主分支，和开发分支。以便下一次上线也会包含本次的紧急修复代码。Support Branch （备用支撑分支）：这个分支的应用比较灵活，有时候如果项目上线的时候基于各种可能性, (比如某个依赖的系统上线失败，或者其他不必要的特性上线失败) 可能会需要准备多个版本，那么Support Branch 就可以作为一条备用分支来使用。这个分支可以根据项目的实际情况来看是否需要使用！各个Branch的示例关系可以看下图我们也可以使用git flow 的一些命令来使用这个工作模式，会有一些既有的命令，使用起来会比较规范，但是也会有一定复杂，项目中可以根据实际情况使用！git flow 相关的一些命令2.4 Forking WorkflowForking WorkFlow 相对与上面的几种协同工作方式有较大的不同。其主要 公共远程仓库 ， 私人远程仓库 ，和 本地仓库 。开发人员一般会从公共远程仓库Fork一份完全一样的代码仓库到自己的 私人远程仓库 。对于私人远程仓库来说，开发人员是拥有者，拥有所有的权限。开发人员可以在本地仓库提交之后随时push到自己的私人远程仓库，随时进行Revert、Reset、Rebase等操作。公共远程仓库为项目的组织官方仓库，保留有不同的分支，以及标签等。可以由私人远程仓库提交Pull Request到公共远程仓库的某个分支，待同事或者一些Owner Review过之后，就可以合并到公共仓库。Forking WorkFlow 也是比较推荐的一种方式，开发人员push代码之后，可以随时在自己的提交基础之上进行Rebase操作，合并之前的许多提交，这样提交历史比较整洁，同时Review也比较方便。3 Git 常见问题及处理方法以及建议。使用Github合并PullRequest的时候，如果代码有冲突，通过网页解决冲突合并之后。Github会进行 双向合并 。关于Git协作，可以考虑Git Flow与Feature flow 还有Forking flow结合使用，Forking Flow有利于整理提交历史，Feature branch对于代码的管理比较友善。本地的代码跑完一次测试的时候就可以提交一版，然后在需要push的时候在rebase合并一次。尽量完善自己的commit信息，写好每一次提交记录。如果merge有问题可以使用git merge --abort 解除merge， 然后再重新合并。多使用Git命令行来进行日常的提交等工作，有助于更好的理解Git的工作原理，这样在不同的IDE上都能比较容易的使用Git插件了。
