在团队开发中，遵循合理清晰的Git使用流程非常重要。否则，每个人都会把提交搞得一团糟，项目很快就会变得难以协调和维护。以下是ThoughtBot的Git使用规范流程。我从中学到了很多，并推荐你也使用Git。第一步：创建新分支首先，每开发一个新功能，都要创建一个单独的分支（这方面请参考《Git分支管理策略》）。#获取主干的最新代码$gitcheckoutmaster$gitpull#创建一个新的开发分支myfeature$gitcheckout-bmyfeature第二步：提交分支commit分支修改完成后，就可以提交commit了。$gitadd--all$gitstatus$gitcommit--verbosegitadd命令的all参数表示保存所有更改（包括新增、修改和删除）。从Git2.0开始，all是gitadd的默认参数，所以你也可以使用gitadd。反而。gitstatus命令用于查看更改的文件。gitcommit命令的verbose参数会列出diff的结果。第三步：写提交信息提交commit时，一定要给出完整简洁的提交信息。以下是模板。现在时摘要50个字符以下*更多关于commit的信息（72个字符以下）。*更多关于commit的信息（72个字符以下）。http://project.management-system.com/ticket/123第一行没有了超过50个字符的摘要，后面跟一个空行，列出更改的原因、主要更改和需要注意的问题。最后，提供相应的URL（例如故障单）。第四步：与主干同步在分支开发过程中，需要经常与主干保持同步。$gitfetchorigin$gitrebaseorigin/master第五步：合并commit分支开发完成后，可能会有一堆commit，但合并到trunk时，往往希望只有一个（或最多两到三个）提交，这不仅清晰，而且易于管理。那么，如何合并多个提交呢？这需要gitrebase命令。$gitrebase-iorigin/mastergitrebase命令的i参数表示交互（interactive），那么git会为下一步打开一个交互界面。下面以TuteCosta的例子来说明如何合并commit。pick07c5abd介绍OpenPGP并教授基本用法使用提交，但编辑提交消息#e,edit=使用提交，但停止修改#s,squash=使用提交，但合并到先前的提交中#f,fixup=类似于“squash”，但丢弃此提交的日志消息#x,exec=runcommand(therestoftheline)usingshell##这些行可以重新排序；他们是从上到下执行的。##如果你在这里删除一行，THATCOMMITWILLBELOST。##但是，如果你删除所有内容，rebase将被中止。##注意空提交被注释掉在上面的交互界面上，首先列出最新的4个提交当前分支的（提交越低，越新）。每次提交前都有一个操作命令。默认是pick，表示选择这一行的commit，进行rebase操作。4次提交下方是一堆注释，列出了可以使用的命令。pick：正常选择reword：选择，修改提交信息；edit：select，rebase时会暂停，允许修改本次commit（参考这里）currentcommitexec：执行其他shell命令上面六个命令中，squash和fixup可以用来合并commit。先把需要合并的commit前面的动词改成squash(或s)。pick07c5abdIntroduceOpenPGPandteachbasicusagesde9b1ebFixPostChecker::Post#urlss3e7ee36Heykids,stopallthehighlightingpickfa20af3gitinteractiverebase,squash,amend有了这个改动，执行后，当前只会剩下两个commit分支。第二行和第三行中的提交将合并到第一行中的提交中。提交信息中也会包含这三个commit的提交信息。#这是3次提交的组合。#第一次提交的消息是：介绍OpenPGP并教授基本用法#这是第二次提交消息：FixPostChecker::Post#urls#这是第三次提交消息：嘿孩子们，停止所有如果第三行的squash命令更改为修复命令，则突出显示。pick07c5abdIntroduceOpenPGPandteachbasicusagesde9b1ebFixPostChecker::Post#urlsf3e7ee36Heykids,stopallthehighlightingpickfa20af3gitinteractiverebase,squash,amend结果是一样的，但是会生成两个提交，第二个和第三个lines提交被合并到第一行提交中。但是在新的提交信息中，第三行commit的提交信息会被注释掉。#这是3次提交的组合。#第一次提交的消息是：介绍OpenPGP并教授基本用法#这是第二次提交消息：FixPostChecker::Post#urls#这是第三次提交消息：#嘿孩子们，停止所有highlightingsquash和fixup命令也可以用作命令行参数来自动合并提交。$gitcommit--fixup$gitrebase-i--autosquash这个用法可以参考这篇文章，这里不再赘述。第六步：推送到远程仓库并合并commit后，就可以将当前分支推送到远程仓库了。$gitpush--forceoriginmyfeaturegitpush命令需要加上force参数，因为rebase后，分支历史发生了变化，可能与远程分支不兼容，可能会被强制推送（见这里).第七步：发出PullRequest并提交到远程仓库后，可以向master分支发出PullRequest，然后请其他人review代码，确认是否可以合并到master中。#p#如果你认真对待编程，你肯定会使用“版本控制系统”（VersionControlSystem）。当下最流行的“版本管理系统”非Git莫属。与同类软件相比，Git有很多优点。最值得注意的一点是版本分支（branch）和合并（merge）非常方便。在一些传统的版本管理软件中，分支操作实际上生成的是现有代码的物理副本，而Git只生成指向当前版本的指针（也称为“快照”），因此速度非常快且易于使用。然而，太方便也会有副作用。一不留神，很可能留下一个四处蔓延开来的版本库，到处都是分支，根本看不到主干的发展。VincentDriessen提出了一个分支管理策略（简体中文版），我觉得值得借鉴。可以保持版本库的演进简洁，主干清晰，各分支各司其职有条不紊。理论上，这些策略适用于所有的版本管理系统，这里仅以Git为例。如果您不熟悉Git，请跳过示例部分。1.主分支Master首先，代码库应该只有一个主分支。所有提供给用户的正式版本都发布在这个master分支上。Gitmaster分支名称，默认为Master。它是自动创建的。版本库初始化后，默认在主分支上开发。2.开发分支Develop主分支仅用于分发大版本，日常开发应在另一个分支上完成。我们称开发分支为Develop。该分支可用于生成最新的隔夜版本代码（nightly）。如果要正式发布，可以将Develop分支“合并”到Master分支上。Git创建Develop分支的命令：gitcheckout-bdevelopmaster将Develop分支发布到Master分支的命令：#切换到Master分支gitcheckoutmaster#合并Develop分支gitmerge–no–ffdevelopHere稍微解释一下，上面一个命令的--no-ff参数是什么意思。默认情况下，Git执行“fast-farward合并”，直接将Master分支指向Develop分支。使用--no-ff参数后，会进行一次正常的merge，在Master分支上生成一个新节点。为了保证版本演进的清晰性，我们希望采用这种方式。有关合并的更多解释，请参阅本杰明桑多夫斯基的《Understanding the Git Workflow》。3.临时分支如前所述，存储库有两个主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实常驻分支只需要这两项，别的什么都不需要。但是，除了永久性分支之外，还有一些用于特定目的版本开发的临时性分支。临时分支主要分为三种：*Feature（特性）分支*Pre-release（发布）分支*Bug修复（fixbug）分支永远只有Master和Develop。4.功能分支接下来我们一一了解这三个“临时分支”。第一个是function分支，它是从Develop分支中分离出来的，目的是为了开发一个特定的功能。开发完成后，必须再次合并到Develop中。特性分支的名称可以采用feature-*的形式命名。创建特性分支：gitcheckout-bfeature-x开发完成后，将特性分支合并到开发分支中：gitcheckoutdevelopgitmerge–no-fffeature-x删除特性分支：gitbranch-dfeature-x第二种release分支是pre-release分支，就是在正式版本发布之前（也就是合并到Master分支之前），我们可能需要有一个pre-release版本来进行测试。预发布分支与开发分支分离。预发布结束后，必须合并到Develop和Master分支。它的命名可以是release-*的形式。创建预发布分支：gitcheckout-brelease-1.2develop确认没有问题后，合并到master分支：gitcheckoutmastergitmerge–no-ffrelease-1.2#为生成的新节点做一个标签mergegittag-a1.2然后合并到develop分支：gitcheckoutdevelopgitmerge–no-ffrelease-1.2最后删除预发布分支：gitbranch-drelease-1.2六、修补bug分支最后是修补错误分支。软件正式发布后，难免会有bug。这时候就需要创建一个分支来修复bug。错误修复分支是从主分支分支出来的。补丁完成后，会合并到Master和Develop分支。它的名字可以是fixbug-*的形式。创建patchbug分支：gitcheckout-bfixbug-0.1master打补丁后合并到master分支：gitcheckoutmastergitmerge–no-fffixbug-0.1gittag-a0.1.1然后合并到develop分支：gitcheckoutdevelopgitmerge--no-fffixbug-0.1最后，删除“fixbugbranch”：gitbranch-dfixbug-0.1
