⼀篇⽂章搞定Git——Git代码管理及使⽤规范
基本概念：
版本库(Repository)是版本控制系统⽤来存放所有历史数据的地⽅，主要存放各个⽂件的当前状态，历史修改时间，谁做的修改，以及修改的原因。举个简单的例⼦，就好⽐银⾏的保险箱，每次往⾥存钱，都会记录谁，什么时间，存放多少钱，存⼊的原因等。对应的版本库（Repository）主要存放代码（⽂档，数据，图标等），并且每⼀次更新都要记录谁，什么时间，提交了什么更新，以及更新的原因是什么。
GIT常⽤配置⽂件
1. .gitgnore忽略⽂件列表
2. .git/config配置⽂件
GIT常⽤命令
GIT分⽀管理
GIT远程分⽀主要包含：master develop feature release fixbug
master：整个项⽬主分⽀，有且仅有⼀个，除项⽬负责⼈以外的开发⼈员不能像master分⽀合并内容。
develop：主分⽀只⽤来分布重⼤版本，⽇常开发应该在另⼀条分⽀上完成。开发⽤的分⽀为Develop。
feature：feature是为了开发后续版本的功能，从Develop分⽀上⾯分出来的。开发完成稳定后，要再并⼊Develop。
release:release是发布正式版本之前（即合并到Master分⽀之前），我们可能需要有⼀个预发布的版本进⾏测试。
fixbug：fixbug分⽀是从master分⽀上⾯分出来的。fix结束以后，再合并进Master和Develop分⽀。最后，删除"fixbug分⽀"。
⼀、主分⽀Master
⾸先，代码库应该有⼀个、且仅有⼀个主分⽀。所有提供给⽤户使⽤的正式版本，都在这个主分⽀上发布。
Git主分⽀的名字，默认叫做Master。它是⾃动建⽴的，版本库初始化以后，默认就是在主分⽀在进⾏开发。
⼆、开发分⽀Develop
主分⽀只⽤来分布重⼤版本，⽇常开发应该在另⼀条分⽀上完成。我们把开发⽤的分⽀，叫做Develop。
这个分⽀可以⽤来⽣成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分⽀上，对Develop分⽀进⾏”合并”（merge）。Git创建Develop分⽀的命令：
$ git checkout -b develop master
将Develop分⽀发布到Master分⽀的命令：
# 切换到Master分⽀
$ git checkout master
# 对Develop分⽀进⾏合并
$ git merge –no–ff develop
这⾥稍微解释⼀下，上⼀条命令的–no–ff参数是什么意思。默认情况下，Git执⾏”快进式合并”（fast-farward merge），会直接将Master分⽀指向Develop分⽀。
使⽤–no–ff参数后，会执⾏正常合并，在Master分⽀上⽣成⼀个新节点。为了保证版本演进的清晰，我们希望采⽤这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Gi
t Workflow》
三、临时性分⽀
前⾯讲到版本库的两条主要分⽀：Master和Develop。前者⽤于正式发布，后者⽤于⽇常开发。其实，常设分⽀只需要这两条就够了，不需要其他了。
但是，除了常设分⽀以外，还有⼀些临时性分⽀，⽤于应对⼀些特定⽬的的版本开发。临时性分⽀主要有三种：
1. 功能（feature）分⽀
2. 预发布（release）分⽀
3. 修补bug（fixbug）分⽀
这三种分⽀都属于临时性需要，使⽤完以后，应该删除，使得代码库的常设分⽀始终只有Master和Develop。
四、功能分⽀
接下来，⼀个个来看这三种”临时性分⽀”。
第⼀种是功能分⽀，它是为了开发某种特定功能，从Develop分⽀上⾯分出来的。开发完成后，要再并⼊Develop。
功能分⽀的名字，可以采⽤feature-*的形式命名。
创建⼀个功能分⽀：
$ git checkout -b feature-x develop
开发完成后，将功能分⽀合并到develop分⽀：
$ git checkout develop
$ git merge –no-ff feature-x
删除feature分⽀：
$ git branch -d feature-x
五、预发布分⽀
第⼆种是预发布分⽀，它是指发布正式版本之前（即合并到Master分⽀之前），我们可能需要有⼀个预发布的版本进⾏测试。
预发布分⽀是从Develop分⽀上⾯分出来的，预发布结束以后，必须合并进Develop和Master分⽀。它的命名，可以采⽤release-*的形式。
创建⼀个预发布分⽀：
$ git checkout -b release-1.2 develop
确认没有问题后，合并到master分⽀：
$ git checkout master
$ git merge –no-ff release-1.2
git常用指令# 对合并⽣成的新节点，做⼀个标签
$ git tag -a 1.2
再合并到develop分⽀：
$ git checkout develop
$ git merge –no-ff release-1.2
最后，删除预发布分⽀：
$ git branch -d release-1.2
六、修补bug分⽀
最后⼀种是修补bug分⽀。软件正式发布以后，难免会出现bug。这时就需要创建⼀个分⽀，进⾏bug修补。
修补bug分⽀是从Master分⽀上⾯分出来的。修补结束以后，再合并进Master和Develop分⽀。它的命名，可以采⽤fixbug-*的形式。
创建⼀个修补bug分⽀：
$ git checkout -b fixbug-0.1 master
修补结束后，合并到master分⽀：
$ git checkout master
$ git merge –no-ff fixbug-0.1
$ git tag -a 0.1.1
再合并到develop分⽀：
$ git checkout develop
$ git merge –no-ff fixbug-0.1
最后，删除”修补bug分⽀”：
$ git branch -d fixbug-0.1
GIT分⽀新建与合并
我们来看⼀个简单的分⽀新建与分⽀合并的例⼦，实际⼯作中你可能会⽤到类似的⼯作流。 你将经历如下步骤：
1. 开发某个⽹站。
2. 为实现某个新的需求，创建⼀个分⽀。
3. 在这个分⽀上开展⼯作。
正在此时，你突然接到⼀个电话说有个很严重的问题需要紧急修补。 你将按照如下⽅式来处理：
1. 切换到你的线上分⽀（production branch）。
2. 为这个紧急任务新建⼀个分⽀，并在其中修复它。
3. 在测试通过之后，切换回线上分⽀，然后合并这个修补分⽀，最后将改动推送到线上分⽀。
4. 切换回你最初⼯作的分⽀上，继续⼯作。
新建分⽀
⾸先，我们假设你正在你的项⽬上⼯作，并且已经有⼀些提交。
现在，你已经决定要解决你的公司使⽤的问题追踪系统中的 #53 问题。 想要新建⼀个分⽀并同时切换到那个分⽀上，你可以运⾏⼀个带有-b参数的git checkout命令：
$ git checkout -b iss53
它是下⾯两条命令的简写：
$ git branch iss53
$ git checkout iss53
你继续在 #53 问题上⼯作，并且做了⼀些提交。 在此过程中，iss53分⽀在不断的向前推进，因为你已经检出到该分⽀（也就是说，你的HEAD指针指向了iss53分⽀）
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
现在有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53的修改混在⼀起，你也不需要花⼤⼒⽓来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这个修改提交到线上分⽀。 你所要做的仅仅是切换回 master 分⽀。
但是，在你这么做之前，要留意你的⼯作⽬录和暂存区⾥那些还没有被提交的修改，它可能会和你即将检出的分⽀产⽣冲突从⽽阻⽌ Git 切换到该分⽀。 最好的⽅法是，在你切换分⽀之前，保持好⼀个⼲净的状态。 有⼀些⽅法可以绕过这个问题（即，保存进度（stashing） 和 修补提交（commit amending））。现在，我们假设你已经把你的修改全部提交了，这时你可以切换回 master 分⽀了：
$ git checkout master
$ Switched to branch 'master'
这个时候，你的⼯作⽬录和你在开始 #53 问题之前⼀模⼀样，现在你可以专⼼修复紧急问题了。
接下来，你要修复这个紧急问题。 让我们建⽴⼀个针对该紧急问题的分⽀（hotfix branch），在该分⽀上⼯作直到问题解决：
$ git checkout -b hotfix
$ vim index.html
$ git commit -a -m 'fixed the broken email address'

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。