一个成功的git分支模型
英文：https://www.sodocs.net/doc/2d5216176.html,/posts/a‐successful‐git‐branching‐model/
参考译文：https://www.sodocs.net/doc/2d5216176.html,/translate/2010/10/30/a‐successful‐git‐branch.html
这篇文章我想介绍一下一年前就提到过的我所有项目(工作/私有)都在使用的开发模式，经过事实验证，确实非常可行。很早就想写了，一直没腾出时间。我不会涉及项目的细节，只是谈谈分支的使用策略和发布管理。
上图是使用Git这个版本控制工具来管理所有源码的。
为什么使用Git
如果要看详细的Git与集中式源码管理工具的优势与劣势，可以参见这篇文章，那里有很多口水仗。作为一个开发人员，所有的源码管理工具中，我最喜欢Git。Git从根本上改变了开发人员对分支和合并的使用，传统的CVS/SVN，分支和合并都是高级话题，而且使用起来稍显麻烦，隔一段时间才会用一次。但是有了Git，这些操作就成了家常便饭。
由于使用简单，方便重复操作，分支和合并不再是让人望而生畏的操作，版本管理工具应该尽可能地对分支/合并提供最好的支持。
工具谈得差不多了，回到开发上。如果想管理好软件的开发流程的话，我待会要讲到的模型其实是一些每个开发人员都应该遵守的步骤。
分布式但集中化
我们要使用的仓库是一个"中心库"，当然这个中心库只是被认为是这样(因为Git是分布式的，从技术层面上来说是没有中心库的)，我们将把这个仓库叫做"origin"，因为Git用户都熟悉这个名字。
每个开发者都可以pull和push到origin，但除了中心化的push-pull关系外，每个开发者还可以从其他开发者那pull changes，来构成小团队。比如说，当开发一个比较大的新特性时，在把正在进行的工作过早地提交到origin之前，安排2个或多个开发者一起协作可能会很有用。上图中有几个小团队：Alice和Bob，Alice和David，Clair和David。
从技术角度来说，其实就是Alice定义了一个叫Bob的Git remote，指向到Bob的仓库，反之亦然。
主(main)分支
中心仓库有两个分支：
At the core, the development model is greatly inspired by existing models out there. 中心仓库有两个无限期存在的主分支：
* master
* develop
origin上的master分支，Git用户应该很熟悉了，跟master并行的有一个叫作develop的分支。
我们把origin/master作为HEAD源码总是表示production-ready(可随时部署)状态的主要分支。
我们把origin/develop作为HEAD源码总是表示下一个发布的最新发展变化状态的主要分支。有时候也叫它为“合并分支”，每日构建也是基于此分支。
当develop分支上的源代码达到了一个稳定状态并准备发布时，所有的改变都要合并到master分支，并标上版本号。如何实现的下面细说。
因此，每次改变合并回master时，都会有新的部署发布。我们对这点非常严格要求，因此从理论上讲，这点可以自动化实现。每次master上有提交时，就可以使用Git hook脚本来构建并发布软件到生产服务器上去。
支持(supporting)分支
我们的开发模型使用了一些支持分支放在master和develop分支的旁边，用来辅助开发小组之间的并行开发，解除特性追踪，准备生产发布和解决生产现场出现的问题。不像主(main)分支，这些分支是有时间限制的，因为他们最终都会被移除。
我们将使用到的不同分支：
* Feature branches
* Release branches
* Hotfix branches
每个分支都有特定的作用并严格规定了它们源自那个分支和将来合并到哪个分支去。这些后面再说。
划分这些分支绝不是从技术层面来的，而是从它们的功能上划分的。它们是十足的旧的git分支。Feature 分支
* 继承分支: develop
* 合并分支：develop
* 命名规范：除了master,develop,release-*,hotfix-*
Feature branches是用来为短期或长期的发布开发新特性。当开始开发新特性时，很可能不知道这个特性会出现在哪个目标版本。一旦开发完成就可以合并到develop，当然如果开发失败，就可以抛弃。
Feature分支一般只存在于develop仓库，不再origin中。
创建一个特性分支
当开发一个新特性时，从develop分支上进行分支
$ git checkout -b myfeature develop
Switched to a new branch "myfeature"
将完成的特性合并到develop中
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
--no-ff(no fast foward)参数，使得每一次的合并都创建一个新的commit 记录。即使合并是fast-foward，这样可以避免丢失feature分支的历史存在，和各小组提交特性的信息。比较下面的两个图：
在右边的情况下，除非手动的阅读所有的日志信息，你不知道是哪个提交对象应用的新特性。回到整个特性(例如一个组的提交)，后一种情况实在让人头疼，所以使用--no-ff参数很容易解决。
可能第一种情况会多创建一些(空的)提交对象，但是收益远大于消费。
不幸的是，我还没有发现一种方法可以让git merge默认带有--no-ff参数，但真的是应该有。
Release 分支
* 继承分支: develop
* 合并分支：develop 和 master
* 命名规范：release-*
Release branchs是为新的production release作准备的。他们可用来做最后的细节问题(dotting of i's and crossing t's)的考虑，甚至允许小的Bug修复和准备发布的元数据(版本号，构建日期等)。在一个发布分支上做完所有的这些工作之后，develop分支被清除来接受下一个大的发布的新特性。
从develop分支合并到release分支的关键点是:develop分支达到了release分支所要求的状态。至少所有针对该release的特性要被合并到develop分支中。至于那些将来会有的特性可以先放一放。然后就是为接下来即将要发布的版本分配一个版本号。
创建发布分支
Release branches是源自develop分支而创建。举个例子，假如1.1.5是当前的production release，然后即将发布一个大的版本发布。develop的状态已经可以发布下一个版本了，经过商榷后，决定它为1.2版本(而不是1.1.6或2.0)。所以我们创建一个release分支，并以新的版本号来命名它。
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.274d9424]Bumped version number to 1.2
1 files changed,1 insertions(+),1 deletions(-)
这个新分支可能会存在一定的时间，直到release被明确的发布。这段时间内，bug修补可以在这个分支上进行(而不是develop分支)。添加新特性(尤其比较大的)是不允许的。他们最后还是要被合并到develop，然后继续在develop分支上开发，直到下一个版本。
完成一个release分支
当release branch已经准备就绪并即将发布，还需要做几件事。首先，release分支将被合并到master 分支上(切记，每一个提交到master上的提交都是一个新版本)。然后，master上的commit都要添加tag，方便将来查看和回滚。最后，release上所做的修改必须合并到develop分支上，以保证将来的发布版的bug已被修补。
前两个步骤是：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.(Summary of changes)
$ git tag -a 1.2
发布版已经做好了，为它打上标签以供将来参考。
注：你可能会想用-s或-u
为了把release上的改变保存到develop，我们需要将它合并回develop中，所以：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
这个步骤可能会导致冲突(因为我们已经改变了版本号)，如果这样的话，解决冲突，然后再提交。
现在一切都完成了，我们不再需要它了，可以把release branch干掉了。 $ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
Hotfix分支
* 继承分支: master
* 合并分支：develop 和 master
* 命名规范：hotfix-*
Hotfix branch和Release branch有几分相似，都是为了新的production release而准备的。比如运行过程中发现了bug，就必须快速解决，这时就可以创建一个Hotfix branch，解决完后合并到master分支上。好处是开发人员可以继续工作，有专人来负责搞定这个bug。
创建Hotfix branch
Hotfix是从master分支上创建的。假如当前运行版本是1.2，然后发现有bug，但是develop还在开发中，不太稳定，这时就可以从master分支新开一个Hotfix branch，然后开始解决问题。
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.141e61bb]Bumped version number to 1.2.1
1 files changed,1 insertions(+),1 deletions(-)
然后，修复Bug并提交
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6]Fixed severe production problem
5 files changed,32 insertions(+),17 deletions(-)
完成Hotfix分支
当结束时，补丁(bugfix)要被合并到master中去，同时也要合并到develop 分支中，以保证下个版本发布时该bug已被修复。这跟release branch完成时一样。
首先，更新master并打上发布标签：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
接下来，也将补丁合并到develop分支：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
有一个例外是，就是当一个release branch存在时，bugfix要被合并到release而不是develop，因为release最终会被合并到develop。(但是，当develop分支急迫的需要这个补丁，不能等待release分支完成，也可以安全的将补丁合并到develop中)。
最后，移除临时的分支：
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1(was abbe5d6).
总结
这个开发模型其实没有什么新颖的，一开始提到的"大图"确实在我们的项目起到了非常大的作用。这是很优雅的一个模型，很容易实现，也容易在团队成员之间达成一致。
git工作流程(阮一峰完整总结版本各流程变化且有独到见解)
Git 工作流程(阮一峰完整总结版本，各流程变化，且有独到 见解) Git 作为一个源码管理系统，不可避免涉及到多人协作。协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 本文介绍三种广泛使用的工作流程： Git flow Github flow Gitlab flow 如果你对Git还不是很熟悉，可以先阅读下面的文章。 《Git 使用规范流程》 《常用Git 命令清单》
《Git 远程操作详解》 一、功能驱动 本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开 发后，该分支就合并到主分支，然后被删除。 二、Git flow 最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。 2.1 特点 它最主要的特点有两个。 首先，项目存在两个长期分支。 主分支master 开发分支develop 前者用于存放对外发布的版本，任何时候在这个分支拿到的，
都是稳定的分布版；后者用于日常开发，存放最新的开发版。其次，项目存在三种短期分支。 功能分支（feature branch） 补丁分支（hotfix branch） 预发分支（release branch） 一旦完成开发，它们就会被合并进develop或master，然后被删除。 Git flow 的详细介绍，请阅读我翻译的中文版《Git 分支管理策略》。 2.2 评价 Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。 更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"，代码一有变动，就部署一次。这时，master分支和develop 分支的差别不大，没必要维护两个长期分支。
Git的分支模型
一个分支可以认为是一个被隔离的工作空间，master和develop是两个长期保留的工作空间，其它的工作空间根据需要随时创建，完成相应任务后，将工作成果合并到develop和maste上，然后删除之。 主要分支 主要分支是所有开发过程中必不可少的分支。原来我都是只用master这一个，现在觉得需要再加develop这一个。 master和develop是两个并行的分支，在代码库创建一开始，就把它们都建好。这两个分支的生命周期最长，应该跟整个产品的生命周期一样。主要分支都创建在origin上。
master分支：我们把正式发版的产品代码放到master分支中。master中的每一次提交，都对应产品的一个版本，HEAD总是最新的版本。 develop分支：是开发用的主要分支，HEAD反应了开发人员为开发下一版本所提交的最新状态。这个分支常用来进行每天晚上的自动构建。 合并时机 develop分支上的代码稳定之后，将要发版之时，将develop合并到master上，并打标签。合并使使用--no-?选项，避免在master上生成大量的revision。（有时在将要发版时，会创建release分支，这时就不是develop分支直接向master合并，而是release分支分别向master和develop合并。） 每一次向master的合并，都是一次定义明确的发版，必须严格遵循这个约定。所以理论上讲，我们可以在master 上加一个触发器，每次提交时，自动触发进行产品新版本的构建。 辅助分支 辅助分支是根据开发需要而创建的分支，它们的生命周期一般不会很长，用完（向master或develop分支合并后）就可以删除了。 辅助分支都是为一个特定目的而创建的，而且，对于它们应该从哪个分支上创建及最后应该合并到哪个分支上，都有严格的约束。 feature分支 分支来源：develop 最后合并：develop 命名规则：除master、develop、release-*、或 hot?x-*之外的都可以。 目的：feather分支是为将来版本开发一个新的功能，这个功能将要在哪个版本中体现还不一定。也可能开发了一段时间之后最后放弃不要了。 feature分支有时可能只存在于开发人员的库中，并没有push到origin上。 新功能开发完成后，合并到develop分支，确定在下一个版本中体现该功能。合并时也要使用--no-?选项。
git merge
一、如何分支的合并 在git中，可以使用git merge和git rebase两个命令来进行分支的合并。 git merge和git rebase在大体上都差不多，下文主要以git merge来例来讲解分支的合并流程。 如果你想了解分支合并的更多内容，请阅读《git merge简介》，《git rebase简介(基本篇)》和《git rebase简介(高级篇)》。 git merge命令示例: $ git merge branchname 这个命令把分支"branchname"合并到了当前分支里面。 如有冲突(冲突--同一个文件在远程分支和本地分支里按不同的方式被修改了）；那么命令的执行输出就像下面一样 $ git merge next 100% (4/4) done Auto-merged file.txt CONFLICT (content): Merge conflict in file.txt Automatic merge failed; fix conflicts and then commit the result. 在有问题的文件上会有冲突标记，在你手动解决完冲突后就可以把此文件添加到索引(index)中去，用git commit命令来提交，就像平时修改了一个文件一样。 如果你用gitk来查看commit的结果，你会看到它有两个父分支：一个指向当前的分支，另外一个指向刚才合并进来的分支。 二、解决合并中的冲突 如果执行自动合并没有成功的话，git会在索引和工作树里设置一个特殊的状态，提示你如何解决合并中出现的冲突。 有冲突(conflicts)的文件会保存在索引中，除非你解决了问题了并且更新了索引，否则执行git commit都会失败: $ git commit file.txt: needs merge 如果执行 git status会显示这些文件没有合并(unmerged),这些有冲突的文件里面会添加像下面的冲突标识符: <<<<<<< HEAD:file.txt Hello world ======= Goodbye >>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt 你所需要的做是就是编辑解决冲突，（接着把冲突标识符删掉），再执行下面的命令: $ git add file.txt $ git commit
Git源代码管理规范样本
Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。
4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程
二、工作原理Git的工作方式:
也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
一个成功的git分支模型
英文：https://www.sodocs.net/doc/2d5216176.html,/posts/a‐successful‐git‐branching‐model/ 参考译文：https://www.sodocs.net/doc/2d5216176.html,/translate/2010/10/30/a‐successful‐git‐branch.html 这篇文章我想介绍一下一年前就提到过的我所有项目(工作/私有)都在使用的开发模式，经过事实验证，确实非常可行。很早就想写了，一直没腾出时间。我不会涉及项目的细节，只是谈谈分支的使用策略和发布管理。
上图是使用Git这个版本控制工具来管理所有源码的。 为什么使用Git 如果要看详细的Git与集中式源码管理工具的优势与劣势，可以参见这篇文章，那里有很多口水仗。作为一个开发人员，所有的源码管理工具中，我最喜欢Git。Git从根本上改变了开发人员对分支和合并的使用，传统的CVS/SVN，分支和合并都是高级话题，而且使用起来稍显麻烦，隔一段时间才会用一次。但是有了Git，这些操作就成了家常便饭。 由于使用简单，方便重复操作，分支和合并不再是让人望而生畏的操作，版本管理工具应该尽可能地对分支/合并提供最好的支持。 工具谈得差不多了，回到开发上。如果想管理好软件的开发流程的话，我待会要讲到的模型其实是一些每个开发人员都应该遵守的步骤。 分布式但集中化 我们要使用的仓库是一个"中心库"，当然这个中心库只是被认为是这样(因为Git是分布式的，从技术层面上来说是没有中心库的)，我们将把这个仓库叫做"origin"，因为Git用户都熟悉这个名字。 每个开发者都可以pull和push到origin，但除了中心化的push-pull关系外，每个开发者还可以从其他开发者那pull changes，来构成小团队。比如说，当开发一个比较大的新特性时，在把正在进行的工作过早地提交到origin之前，安排2个或多个开发者一起协作可能会很有用。上图中有几个小团队：Alice和Bob，Alice和David，Clair和David。 从技术角度来说，其实就是Alice定义了一个叫Bob的Git remote，指向到Bob的仓库，反之亦然。 主(main)分支 中心仓库有两个分支：
GIT Flow分支与流程说明
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分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
gitlab代码版本管理流程2020414
GitLab代码开发管理 一,分支管理 GitLab固定三个分支及其关系master-->release-->development,三个分支只有Maintainers允许merge,允许push. 设置方法:Settings-->Repository-->Protected Branches可以添加保护分支策略,如下图: 图1.1分支保护 成员分支: 每个成员须从development分支下创建自己的开发分支,命名规则development_xxx_bugfix或者development_xxx_newfeatures等,xxx代表开发者名字全拼. 二,开发管理 开发提交代码步骤: 1,成员在自己拥有的分支上开发new features或者bug fix 2,完成之后push到自己的分支 3,创建merge request到development分支并指向研发负责人 4,研发负责人收到merge request后进行code review 5,没有问题之后研发负责人merge此次request;有问题的话和开发者说出问题所在,并且关闭此次merge request
图2.1开发提交代码步骤流程 三,发版管理 待测试完成测试后,分支需由研发负责人按照development-->release-->master进行merge,最终master分支保留有本次版本开发的最新最全没有bug的代码 四,tag管理 新版本发布后必须创建tag封版本,方便以后对之前版本和问题的追踪管理 具体步骤:Repository-->Tags-->New tag
图3.1创建tag
Git版本控制系统的使用方法
Git版本控制系统的使用方法 一、Git简介 Git是一个分布式版本控制系统，是用来追踪计算机文件的变化的工具，也是一个供多人使用的协同工具。每个人都可以拥有一个完整的版本库。分布式版本控制系统的几乎所有操作包括查看提交日志、提交、创建里程碑和分支、合并分支、回退等都可以直接在本地完成而不需要网络连接。 二、Git客户端的下载和安装 Git官方客户端为Git Bash，Git bash是以命令行的形式来操作的，另外本使用方法中可视化软件采用了sourcetree，Git bash和sourcetree的使用请自行选择，用户需先下载Git和sourcetree。 1.Git的下载和安装： 1) 官网地址：https://https://www.sodocs.net/doc/2d5216176.html,/ 进入Git官网，由于电脑是Windows系统，选择Downloads for Windows。 2) 右键以管理员身份运行下载的安装包。
3) 选择安装路径 4) 一直点击Next按钮，当出现下图情况时选择“Use Windows’default console window”，然后点击“Next”
5) 继续点击“Next”，最后点击“Install”，等待安装完成。 6) 在开始菜单中打开Git CMD 在CMD中输入Git，出现Git的相关提示说明安装成功，如下图所示： 参考文档：https://www.sodocs.net/doc/2d5216176.html,/s?id=1601036689157983619&wfr=spider&for=pc
2.Sourcetree下载和安装： 1)首先，下载windows版本的企业版sourceTree。直接进入官网 https://https://www.sodocs.net/doc/2d5216176.html,/enterprise下载 2)进入下载保存sourceTree的目录，双击SourceTreeEnterpriseSetup_3.0.17.msi文件进行 安装
(完整版)gitlabissue详细操作流程
gitlab issue详细操作流程 issue概述 一般master分支默认是被锁住，其目的是保护该分支。普通开发人员可以创建issue后建立对应的分支然后去完成任务。完成issue后便要合并分支，只需发送merge request ，等待owner审核通过才能合并到master分支上。合并的过程中可能会出现代码冲突问题。而这个问题却交给了owner去处理，因为普通开发人员是没有权限的。 Issue 指的是一项待完成的工作，通常与系统的改进相关，中文可以译为'问题'或'事务'。下面这些都是 Issue 的例子。 一个软件的 bug。 一项功能建议。 一项待完成的任务。 文档缺失的报告。 每个 Issue 应该包含该问题的所有信息和历史，使得后来的人只看这个 I ssue，就能了解问题的所有方面和过程。历史上，Issue 起源于客服部门。用户打电话反映问题，客服就创建一个工单（ticket），后续的每一个处理步骤、每一次与用户的交流，都要更新工单，记录全部信息。这就是 Issue 的前身。因此，Issue 的原始功能是问题追踪和工单管理，后来不断扩展，逐渐演变成全功能的项目管理工具，还可以用于制定和实施软件的开发计划。 除了软件，其他项目也可以使用 Issue，比如有人把自己住宅的改善计划都做成了 Issue
Issue操作流程 1.what用户克隆代码到本地。 假如我们创建好了项目，并添加了开发人员what账户。项目地址是： http地址：http://192.168.99.102/root/cloud-dev.git Ssh地址：git@192.168.99.102:root/cloud-dev.git 作为一个开放人员what，第一步我们需要将仓库拉到本地电脑上去。为了方便拉取仓库，这里详细说明下用sshkey秘钥认证拉取仓库。在what研发电脑上创建一个秘钥。打开Gui，选择Help-Show SSH Key。
基于Git开发命令
←git clone ssh://lmmeng@https://www.sodocs.net/doc/2d5216176.html,:29418/test && scp-p -P 29418 lmmeng@https://www.sodocs.net/doc/2d5216176.html,:hooks/commit-msg ResCRMOnline /.git/hooks/ ←cd ResCRMOnline ←git checkout origin/develop -b develop （创建本地开发分支，并且换上去） ←git branch localdev （建立本地开发分支） ←git checkout localdev (切换到本地开发分枝) ←... make some changes and commits ... ←git status ←git add . / git add -A （加入需要提交的文件<所有>） ←git log -3 （查看本地签入历史） ←git checkout develop （切换至本地开发分支） ←git pull （获取远程修改） ←git merge --squash localdev（合并本地分支localdev至开发分支develop，如果有多个commit，会合并成一个，并且处于待commit的状态） ←git commit --amend（原有版本的追加commit，使之合并为还是原有版本） ←git commit -m “message”（另外新建一个新版本commit） ←... develop completed ... ←git push origin HEAD:refs/for/develop （推送本地develop分支到远程origin/develop 分支，做CodeReview） git checkout develop （切换至本地开发分支） git pull （获取远程修改） git status git add -A （加入需要提交的文件<所有>） git commit -m “message”（另外新建一个新版本commit，message是要标记的commit信息）,第二次修改git commit --amend git push origin HEAD:refs/for/develop （推送本地develop分支到远程origin/develop分支，做CodeReview） $ git reset --hard d7*******d6d533493704e806b587df5e20864e2 $ git rebase oring/develop $ git show $ git checkout origin/develop -b Tmp1 $ git cherry-pick 41330324809703d8769ada05f026cd917b59ca1a $ git co origin/develop -b Tmp1 $ git show 41330324809703d8769ada05f026cd917b59ca1a $ git rebase $ git push origin HEAD:refs/for/develop%r=ydtan,r=zwyu,r=qinq
Git版本控制的安装使用指南
1. 概述 Git是基于Linux内核开发的分布式版本控制／软件配置管理软件，与CVS、Subversion 等集中式版本控制软件不同，Git采用分布式管理，不需要服务器端软件即可运行。Git速度很快，并且具有很出色的合并追踪能力。很多有名的软件开发都使用Git来进行版本控制，其中有Linux内核、https://www.sodocs.net/doc/2d5216176.html,服务器和OLPC内核开发等。 作为开源软件的代表，Git不对版本库的浏览和修改作任何的权限限制，因此只能采用其他工具实现权限管理，如gitosis、gitolite、CodeBeamer MR。 原本Git的使用只限于Linux/Unix，由于Cygwin、msysgit、TortoiseGit等GUI工具的出现，在Windows平台的使用逐渐成熟。 2. Git安装 2.1 安装Git 安装Git作为客户端，运行客户端可通过Git Bash（Git的命令行）或Git GUI操作。Windows下使用Git-1.7.8-preview20111206.exe，安装要点如下：
上述图片所示选项，似乎也不确定，网上帖子安装教程各种选项都有。安装完后，点击桌面Git Bash启动，执行命令pwd查看默认进入的文件目录，执行下面命令：mkdir .ssh （注意文件名前有.），即在默认目录下建立.ssh文件夹。修改环境变量，桌面右击我的电脑， 在属性中选择高级选项，左击环境变量，在系统变量中选择新建或编辑
下面列出一些问题的解决方法： a. Git Bash中ls不能显示中文目录（可直接打开编辑）：在 git/etc/git-completion.bash中增加一行： alias ls='ls --show-control-chars --color=auto'，注意引号为中文单引号，重启Git Bash b. Git commit不能提交中文注释：修改git/etc/inputrc中对应的行： set output-meta on set convert-meta off c. git log无法显示中文注释，在git/etc/profile中增加一行： export LESSCHARSET=iso8859 安装完后，需要在Git Bash中注册本人信息： git config --global https://www.sodocs.net/doc/2d5216176.html, Your Name git config --global user.email your@email.address 在服务端，即Ubuntu，安装Git： sudo apt-get install git-core git-doc 3. Gitolite安装
git分支管理
一、主分支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 三、临时性分支 前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。 但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种： * 功能（feature）分支 * 预发布（release）分支
* 修补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
git使用指南
Git使用指南 Li Yanrui v0.1,20080728 liyanrui.m2@https://www.sodocs.net/doc/2d5216176.html,
前言 Git是什么 非常简单地说，Git是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。所谓版本控制系统(Version Control System)，从狭义上来说，它是软件项目开发过程中用于储存我们所写的代码所有修订版本的软件，但事实上我们可以将任何对项目有帮助的文档交付版本控制系统进行管理。 2005年，Torvalds开始着手开发Git是为了作为一种过渡方案来替代BitKeeper，后者之前一直是Linux内核开发人员在使用的版本控制工具，当时由于自由软件社区中的许多人觉得BitKeeper的使用许可证并不适合自由软件社区的工作，因此Linus决定着手开发许可证更为自由灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程，但是现在很多其他自由软件项目中也使用了Git实现代码版本管理，譬如，https://www.sodocs.net/doc/2d5216176.html,项目、许多https://www.sodocs.net/doc/2d5216176.html,的项目、Ruby项目等。 为什么使用版本控制系统 版本控制系统是为懒人准备的，它让懒人们比那些善于备份文档的勤劳人拥有更干净的文件系统以及更多的可以活着的时间。 本文档主要内容 在第1章中讲述如何使用Git管理自己的个人文档，主要是初步熟悉Git的诸多概念及其日常基本命令的使用。第2章中主要讲述如何基于Git实现多人协作的项目开发模式，以此扭转当前实验室成员在项目研发中各自为政或不能有效沟通的现状。第3章讲述如何利用Git强大的项目分支管理功能实现良好风格的项目协同开发模式。第4章为Git使用之FAQ，用于记载在本实验室推广使用Git过程中诸位同学所遇到的一些细节问题。
git常用命令集详解
git使用记录 1.生成密匙： ssh-keygen-t rsa几次回车，在.ssh/下的id_rsa.pub即为密匙文件； 2.获取git分支： A.远程获取：（路径须绝对路径） git clone git@192.168.1.50:/home/git/repositories/A20-Android4_2.git. （注意在最后加个点是为了避免clone时在当前目录下新建一个git目录） B.本地获取：（路径为相对路径即可） git clone git@192.168.1.50:A20-Android4_2.git. C.查看所获取分支的路径： git remote-v D.切换到某个分支： git checkout$branchname 3.分支的新建与删除： A.新建： git branch$branchname（注意在哪个分支上执行就是基于哪个分支新建） git push origin$branchname（推到服务器仓库） B.删除： git branch-D$branchname（删除本地的分支） git branch-rd origin/$branchname（删除服务器仓库分支） git push origin:$branchname（注意冒号） git remote prune origin（同步远端已删除分支）
4.修改内容查看及提交： A.查看未提交的修改： git status/git status.（查看修改的文件） git diff/git diff.（查看修改的内容） B.查看已提交修改： git log（查看提交信息） git whatchanged（查看每个提交修改的文件） git diff$2$1（查看莫个"提交ID"$1的修改内容） C.还原被修改文件： git checkout-f*/$fileanme D.提交修改： git add*/$filename（将新建文件加入仓库） git commit*/$filename-m"***"/git commit-a-m""（提交修改/提交当前所有修改，删除一个文件也可以） git push origin$branchname E.还原到某个提交ID前： git reset“$提交ID”（注意避免冲突：如果本地有修改过即将还原的文件，可以先备份it，然后git checkout-f$it） git push origin$branchname--force git pull origin$branchname F.提取同一仓库不同分支的修改： git cherry-pick“$提交ID”
git分支原理命令图文解析
本地分支解析 git 通过可变指针来实现对提交数据的历史版本的控制，每当我们提交新的更新，当前分支(设为master)则指向最后一个提交更新A，而最后一个提交对象则存在一个指针指向前一次的提交更新Q。如果我们创建一个新的分支，child，它和master共同指向A，这时，如果我们向child分支提交更新B，我们会发现child 指向B，而master依然指向A。无论我们在child分支进行了任何开发，只要回到master分支，就能恢复到更新A的数据状态了。 在图片里，我们还注意到有一个head指针，一般来说，它会指向我们目前所在的工作分支。现在它指向了我们的master分支，意思是master是我们目前的工作分支。一旦提交更新，就会在master分支上提交。现在，让我们看看与git 分支有关的操作命令： 1. git branch [option] [name] 如果不使用任何参数，它可以用来查看所有的分支,而在分支名前有*标记的则为主分支，如果加上name为创建新分支，,如git branch child,则会创建一个名为child 的分支，此外，它有一些常用的参数：
2. git checkout [name] 切换到对应的分支，对于上图，如果我们是使用git checkout child，我们的head 指针就会指向child分支了。这时候，如果我们提交新的更新D，我们会发现： 我们的D指向C，而C依然指向A，也就是说，以后我们在child分支上做的任何更新，都不会对master分支所在的之路造成任何影响！一旦使用了checkout
命令，我们还会发现，不仅head指针会指向新的分支，而且当前工作目录中的文件也会换成了新分支对应的文件了。 此外，我们还可以使用git checkout -b [name]命令，它会新建一个分支，并自动将当前的工作目录切换到该分支上。 3. git merge [name] 合并分支，有的时候，我们创建次要分支，可能是为了修改原有程序的bug，或为了拓展新的功能，这时候如果我们想把次要分支的修改何并进主分支中，我们可以使用git merge命令来实现。 1. “Fast forward”(快进)式合并: 如果像上图所示，我们要把child分支合并进master中，因为child分支所指向的更新在master分支的直接上游，git会使用“Fast forward”(快进)式合并，直接将master分支指针指向child分支所指向更新，如下图所示： 这时候，如果我们觉得child分支没什么用了，我们可以使用git branch -d child 来删除分支。 2. 基本合并 如果我们这次要合并的分支不在我们目前分支的上游，如下图所示：
Git版本管理工具操作规范
Git版本管理工具操作规范
2017年5月
修改记录
目录 １引言.................................................................. - 7 -１.１文档目的....................................................... - 7 -１.２适用对象....................................................... - 7 -１.３适用范围....................................................... - 7 -２分支命名规范.......................................................... - 7 -３操作规范.............................................................. - 8 -３.１ OA 系统........................................................ - 8 -３.１.１工作流.................................................. - 8 - ３.１.２开发人员日常操作规范.................................... - 8 -３.１.２.１克隆分支......................................... - 8 - ３.１.２.２创建新分支....................................... - 8 - ３.１.２.３提交修改内容..................................... - 9 - ３.１.２.４推送自己的开发分支到远端......................... - 9 - ３.１.２.５合并自己的开发分支到主开发分支................... - 9 -３.１.３测试人员日常操作........................................ - 9 -３.１.３.１克隆分支......................................... - 9 - ３.１.３.２创建新分支操作.................................. - 10 - ３.１.３.３合并开发人员的代码.............................. - 10 -
git常用命令解说
1. Git概念 1.1. Git库中由三部分组成 Git 仓库就是那个.git 目录，其中存放的是我们所提交的文档索引内容，Git 可基于文档索引内容对其所管理的文档进行内容追踪，从而实现文档的版本控制。.git目录位于工作目录内。 1）工作目录：用户本地的目录； 2） Index（索引）：将工作目录下所有文件（包含子目录）生成快照，存放到一个临时的存储区域，Git 称该区域为索引。 3）仓库：将索引通过commit命令提交至仓库中，每一次提交都意味着版本在进行一次更新。 1.2. 使用Git时的初始化事项 1.2.1. Git初始化配置 1）配置使用git仓库的人员姓名 git config --global https://www.sodocs.net/doc/2d5216176.html, "Your Name Comes Here" 2）配置使用git仓库的人员email git config --global user.email you@https://www.sodocs.net/doc/2d5216176.html,
1.2.2. Git文档忽略机制 工作目录中有一些文件是不希望接受Git 管理的，譬如程序编译时生成的中间文件等等。Git 提供了文档忽略机制，可以将工作目录中不希望接受Git 管理的文档信息写到同一目录下的.gitignore 文件中。 例如：工作目录下有个zh目录，如果不想把它加入到Git管理中，则执行： echo “zh” > .gitignore git add . 有关gitignore 文件的诸多细节知识可阅读其使用手册：man gitignore 1.3. Git与Repo的比较 Git操作一般对应一个仓库，而Repo操作一般对应一个项目，即一个项目会由若干仓库组成。 例如，在操作整个Recket项目时使用Repo，而操作其中的某个仓库时使用Git。在包含隐藏目录.git的目录下执行git操作。 2. Git help Git help 获取git基本命令 （如果要知道某个特定命令的使用方法，例如：使用Git help clone，来获取git clone 的使用方法） 3. Git本地操作基本命令 3.1. Git init 或者使用git init-db。 创建一个空的Git库。在当前目录中产生一个.git 的子目录。以后，所有的文件变化信息
使用TortoiseGit操作分支的创建与合并
使用TortoiseGit操作分支的创建与合并第一步：创建本地分支 点击右键选择TortoiseGit，选择Create Branch…，在Branch框中填写新分支的名称（若选中”switch to new branch”则直接转到新分支上，省去第二步），点击OK按钮： 第二步：通过“Switch/Checkout”切换到新创建的分支上，点击OK：
第三步：在新分支下执行PUSH操作，在对话框中保持远程分支为空白，点击OK，则将在远程创建了新的分支（在PUSH的时候远程服务器发现远程没有该分支，此时会自动创建一个和本地分支名称一样的分支，并将本地分支的内容上传到该分支）。
第四步：其他成员切换该新分支： 首先进行pull操作， 然后进行切换分支（如第二步） 第五步：分区合并 进行分支合并之前我们需要明确哪个分支将要合并到哪个分支，首先通 过“Switch/CheckOut”切换到主干分支（如develop分支）,然后通过“Merge”继进行合并操作，在对话框中选择需要合并的分支。 分支合并成功后，我们即可以通过Commit与PUSH操作将合并上传到中心服务器。
第六步：删除分支 当我们已将新分支合并到主分支后，或者放弃该分支的时候，可以对该分支进行删除操作。 首先通过“CheckOut/Switch”打开对话框，点击Switch to区域中Branch条目后面的更多按钮，打开分支列表对话框，右键点击要删除的分支，选择delete branch进行删除。 注意，在删除远程分支的时候，本地分支并不会删除，这也说明了本地分支与远程分支并无从属关系。