#新建代码库
git init # 在当前目录新建一个Git代码库
git init [project-name] # 新建一个目录，将其初始化为Git代码库
git clone [url] # 下载一个项目和它的整个代码历史
#配置git
git config [--global] user.name "your name"
git config [--global] user.email "your email address"
#分支
git branch -r # 查看远程分支
git br -v # 查看各个分支最后提交信息
git checkout [branch-name] # 切换到指定分支，并更新工作区
#标签
git tag # 列出所有tag
git show [tag] # 查看tag信息
#远程同步
git remote -v # 显示所有远程仓库
git remote show [remote] # 显示某个远程仓库的信息
git fetch [remote] # 下载远程仓库的所有变动
git pull [remote] [branch] # 取回远程仓库的变化，并与本地分支合并
git开发模型
feature br - develop br - release br - hotfix br - master - tag
exampleproj
|-- exampleproj-master-tag-0.1
|-- exampleproj-develop
|-- exampleproj-feature
|-- exampleproj-develop
|-- exampleproj-release
|-- exampleproj-hotfix
|-- exampleproj-master-tag-0.2
...
git经典协同模型：
中心仓库：包含master和develop两个分支
分支分类：
- 主要分支：master和develop分支
- 支持性分支：特性分支，发布分支，热补丁分支
简单介绍一下的各种分支：
- Master - 与产品环境代码保持一致的分支，也就是每次发布完成之后发布的功能分支就要合并于此，以保持Master更新。
- Develop - 开发的主分支，Feature和Release分支会基于此分支。
- Feature - 具体要开发的功能的分支，完成后合并到Develop。
- Release - 用于发布新版本的分支，完成后合并到Develop和Master。
- HotFix - 用于紧急修复已发布的产品问题的分支，完成后合并到Develop和Master。
最右边的是主分支，黄色的是develop分支，比如开发版本1.0，开发过程中master出现问题要修改，产生的就是红色点的，叫热补丁分支。
红色的热补丁分支修改完成后，除了要合并到master外，还要合并到正在开发的develop分支，这样之后更新的版本如2.0合并到master后才不会出现同样的bug。完成后热补丁分支也就完成使命，可以销毁了。
绿色部分的为发布分支。即当版本1.0（黄色部分）开发完成后，黄色部分可能继续开发下去，比如接着开发2.0，然后将1.0的版本以发布分支独立处出来，进行测试阶段的运行，然后途中出现问题，修复并且合并到develop分支，当该版本不再出现问题后没，即可将该分支合并到master，同时也要何合并到正在开发的develop分支（因为如果发布分支有修复了bug的话，合并后才能使下一个版本不会出现同样的bug），完成后，发布分支使命也完成了。
最左边的紫红色部分，为特性分支，即当你在开发产品时，突发奇想想到了新功能或者新的解决方法或者其它等新尝试，但不敢保证可以完成这部分的开发，所以以特性分支独立出来开发。如果开发能够完成，既可以合并到develop分支里。
Git Flow中的分支
主分支
主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。
master分支
master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
develop分支
develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
因此，每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。通常而言，“仅在发布新的可供部署的代码时才更新master分支上的代码”是推荐所有人都遵守的行为准则。基于此，理论上说，每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
辅助分支
辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。
辅助分支包括：
- 用于开发新功能时所使用的feature分支；
- 用于辅助版本发布的release分支；
- 用于修正生产代码中的缺陷的hotfix分支。
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。
feature分支
使用规范：
- 可以从develop分支发起feature分支
- 代码必须合并回develop分支
- feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称
feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
release分支
使用规范：
- 可以从develop分支派生
- 必须合并回develop分支和master分支
- 分支命名惯例：release-*
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
hotfix分支
使用规范：
- 可以从master分支派生
- 必须合并回master分支和develop分支
- 分支命名惯例：hotfix-*
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
常用分支命名示例：
tag/1.0.1 标签
master 主要
develop/1.0.2 开发
feature/my-xxx-feature 新功能 （创建自develop分支，开发完成后先合并到develop，然后删除分支）
release/1.1 预发布 （创建自develop分支，确定没问题合并到master和develop，然后删除分支）
fixbug-name 修复bug （创建自master分支，开发完成后合并到master和develop，然后删除分支）
hotfix-name 补丁 （创建自master分支，确定合并到master和develop，然后删除分支）
参考文章：
http://blog.csdn.net/dengsilinming/article/details/8000622 [Git 常用命令大全]
http://www.cnblogs.com/cspku/articles/Git_cmds.html [Git常用命令]
http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html [常用 Git 命令清单]
http://blog.csdn.net/zymx14/article/details/53415231?locationNum=11&fps=1 [git原理图及git协同模型]
http://www.oschina.net/translate/a-successful-git-branching-model [介绍一个成功的 Git 分支模型]
http://blog.csdn.net/gong0791/article/details/47148989 [常用 Git 开发模型]
http://www.cnblogs.com/itech/p/5188929.html [四种常见 Git 工作流比较]
http://www.jianshu.com/p/ca5ee4ea6420 [Git 工作流的一些经验分享]
http://blog.jobbole.com/76867/ [Git工作流指南：Gitflow工作流]
https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html [Git 分支管理最佳实践]
http://semver.org/lang/zh-CN/ [语义化版本 2.0.0]
http://cheenwe.cn/2016-08-02/git-branch-and-usage/ [Git分支命名规范]
http://blog.sina.com.cn/s/blog_70c0040c0102vlkt.html [Git分支管理策略]
http://www.yiibai.com/git/git_handling_conflicts.html [Git处理冲突]
http://www.cnblogs.com/best/p/7474442.html [一个小时学会Git]
|
版权声明：本文采用署名-非商业性使用-相同方式共享(CC BY-NC-SA 3.0 CN)国际许可协议进行许可,转载请注明作者及出处。 |