git分支实例
分支的新建
首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。
图 3-10. 一个简短的提交历史
现在，你决定要修补问题Qone系统上的 #53 问题。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 git checkout 并加上 -b 参数：
$ git checkout -b iss53
Switched to a new branch "iss53"这相当于执行下面这两条命令：
$ git branch iss53
$ git checkout iss53图 3-11 示意该命令的执行结果。
图 3-11. 创建了一个新分支的指针
接着你开始尝试修复问题，在提交了若干次更新后，iss53 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 HEAD 指针正指向 iss53，见图 3-12）：
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
图3-12. iss53 分支随工作进展向前推进
现在你就接到了那个网站问题的紧急电话，需要马上修补。有了Git 唯一需要的仅仅是切换回master 分支。假设目前已经提交了所有的修改，所以接下来可以正常转换到master 分支：
$ git checkout master
接下来，你得进行紧急修补。我们创建一个紧急修补分支 hotfix 来开展工作，直到搞定（见图 3-13）：
$ git checkout -b 'hotfix'
图3-13. hotfix 分支是从master 分支所在点分化出来的
有必要作些测试，确保修补是成功的，然后回到master 分支并把它合并进来，然后发布到生产服务器。用git merge 命令来进行合并：
$ git checkout master
$ git merge hotfix
在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 hotfix 分支和 master 都指向相同的提交对象，所以 hotfix 已经完成了历史使命，可以删掉了。使用 git branch 的 -d 选项执行删除操作：
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).现在回到之前未完成的 #53 问题修复分支上继续工作（图
3-15）：
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53]: created ad82d7a: "finished the new footer [issue 53]"
1 files changed, 1 insertions(+), 0 deletions(-)
用担心之前 hotfix 分支的修改内容尚未包含到 iss53 中来。如果确实需要纳入此次修补，可以用git merge master 把 master 分支合并到 iss53；或者等 iss53 完成之后，再将 iss53 分支中的更新并入 master。
分支的合并
在问题 #53 相关的工作完成之后，可以合并回 master 分支。实际操作同前面合并 hotfix 分支差不多，只需回到 master 分支，运行 git merge 命令指定要合并进来的分支：
$ git checkout master
$ git merge iss53
这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 master 分支所指向的提交对象（C4）并不是iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象：
图 3-16. Git 为分支合并自动识别出最佳的同源合并点。
既然之前的工作成果已经合并到 master 了，那么 iss53 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。
$ git branch -d iss53
遇到冲突时的分支合并
有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）
要看看哪些文件在合并时发生冲突，可以用git status 查阅：
何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
在解决了所有文件里的所有冲突后，运行git add 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）
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源代码管理规范样本
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最重要的部分。
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
(完整版)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分支模型
英文：https://www.sodocs.net/doc/de1818119.html,/posts/a‐successful‐git‐branching‐model/ 参考译文：https://www.sodocs.net/doc/de1818119.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分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
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/de1818119.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/de1818119.html,/s?id=1601036689157983619&wfr=spider&for=pc
2.Sourcetree下载和安装： 1)首先，下载windows版本的企业版sourceTree。直接进入官网 https://https://www.sodocs.net/doc/de1818119.html,/enterprise下载 2)进入下载保存sourceTree的目录，双击SourceTreeEnterpriseSetup_3.0.17.msi文件进行 安装
Git版本控制的安装使用指南
1. 概述 Git是基于Linux内核开发的分布式版本控制／软件配置管理软件，与CVS、Subversion 等集中式版本控制软件不同，Git采用分布式管理，不需要服务器端软件即可运行。Git速度很快，并且具有很出色的合并追踪能力。很多有名的软件开发都使用Git来进行版本控制，其中有Linux内核、https://www.sodocs.net/doc/de1818119.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/de1818119.html, Your Name git config --global user.email your@email.address 在服务端，即Ubuntu，安装Git： sudo apt-get install git-core git-doc 3. Gitolite安装
git使用指南
Git使用指南 Li Yanrui v0.1,20080728 liyanrui.m2@https://www.sodocs.net/doc/de1818119.html,
前言 Git是什么 非常简单地说，Git是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。所谓版本控制系统(Version Control System)，从狭义上来说，它是软件项目开发过程中用于储存我们所写的代码所有修订版本的软件，但事实上我们可以将任何对项目有帮助的文档交付版本控制系统进行管理。 2005年，Torvalds开始着手开发Git是为了作为一种过渡方案来替代BitKeeper，后者之前一直是Linux内核开发人员在使用的版本控制工具，当时由于自由软件社区中的许多人觉得BitKeeper的使用许可证并不适合自由软件社区的工作，因此Linus决定着手开发许可证更为自由灵活的版本控制系统。尽管最初Git的开发是为了辅助Linux内核开发的过程，但是现在很多其他自由软件项目中也使用了Git实现代码版本管理，譬如，https://www.sodocs.net/doc/de1818119.html,项目、许多https://www.sodocs.net/doc/de1818119.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分支管理
一、主分支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版本管理工具操作规范
2017年5月
修改记录
目录 １引言.................................................................. - 7 -１.１文档目的....................................................... - 7 -１.２适用对象....................................................... - 7 -１.３适用范围....................................................... - 7 -２分支命名规范.......................................................... - 7 -３操作规范.............................................................. - 8 -３.１ OA 系统........................................................ - 8 -３.１.１工作流.................................................. - 8 - ３.１.２开发人员日常操作规范.................................... - 8 -３.１.２.１克隆分支......................................... - 8 - ３.１.２.２创建新分支....................................... - 8 - ３.１.２.３提交修改内容..................................... - 9 - ３.１.２.４推送自己的开发分支到远端......................... - 9 - ３.１.２.５合并自己的开发分支到主开发分支................... - 9 -３.１.３测试人员日常操作........................................ - 9 -３.１.３.１克隆分支......................................... - 9 - ３.１.３.２创建新分支操作.................................. - 10 - ３.１.３.３合并开发人员的代码.............................. - 10 -
idea+git合并分支解决冲突及详解步骤
idea+git合并分支解决冲突及详解步骤 这篇文章主要介绍了idea+git合并分支解决冲突及详解步骤,文中通过示例代码介绍的非常详细，对大家的学习或 者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧 Git分支详解参考： 分支管理组成 1.1、master主干 在版本管理中，代码库应该仅有一个主干。此主干是和当前生产保持一致的，是可用的、稳定的可直接发布的版本，不能再主干上进行任何开发操作。git主干的名字，默认叫做 master，它是自动建立的。 1.2、develop主开发分支 因为不能在主干master上进行开发，那么就需要在基于主干master的基础上，创建一个开发主分支develop，开发主分支develop的代码永远是最新的，所有的新功能都是以此分支为基础进行开发的，该分支只是做合并操作，也不能在此分支进行实际开发。 1.3、feature功能开发分支 功能开发分支，在develop上创建分支，采用“feature-” +“分支创建时间”+ “批次名称-”的命名规范。 例如：“feature-20190301-XXX” 此分支既作为需求开发分支又作为需求测试分支，所有需上线内容需在当前分支充分测试通过后，才可提交test分支与其他待上线分支代码进行合并，然后进行test分支回归测试。 1.4、test测试分支 test分支它是指发布正式版本之前（即合并到 master分支之前），我们需要有一个预发布的版本进行测试。 预发布分支是从develop分支上面分出来的，预发布部署生产验证无误，结束以后，必须向下合并进 master和develop 分支以及develop衍生所有开发分支，保证各分支基线版本与生产基线同步。 1.5、hotfix紧急bug分支 项目上线后会遇到一些需要紧急修复的bug，那么就需要创建一个紧急bug修改分支，此分支需要从master直接拉取分支进行开发修改，修复完成后必须向下合并进 master和develop分支以及develop衍生所有分支，保证各分支基线版本与生产基线同步。 采用 “hotfix-” +“分支创建时间”+“bug号或bug描述”的命名规范。 例如：“hotfix-20190116-001” 1、切换分支 1）在idea页面右下角点击分支名 2）在git 分支选择框中选择项目一步步选择需要的分支 这里先演示切换到master主干分支，点击Checkout切换
GIT分支管理是一门艺术
英文原文： https://www.sodocs.net/doc/de1818119.html,/posts/a-successful-git-branching-model/ 原文作者：Vincent Driessen 1 GIT，在技术层面上，绝对是一个无中心的分布式版本控制系统，但在管理层面上，我建议你保持一个中心版本库。 2 我建议，一个中心版本库(我们叫它origin)至少包括两个分支，即“主分支(master)”和“开发分支(develop)”
3 要确保：团队成员从主分支(master)获得的都是处于可发布状态的代码，而从开发分支(develop)应该总能够获得最新开发进展的代码。 4 在一个团队开发协作中，我建议，要有“辅助分支”的概念。 5 “辅助分支”，大体包括如下几类：“管理功能开发”的分支、“帮助构建可发布代码”的分支、“可以便捷的修复发布版本关键BUG”的分支，等等。 6 “辅助分支”的最大特点就是“生命周期十分有限”，完成使命后即可被清除。 7
我建议至少还应设置三类“辅助分支”，我们称之为“Feature branches”，“Release branches”，“Hotfix branches”。 至此，我们形成了如下这张最重要的组织组，包含了两个粗体字分支（master/develop）和三个细体字分支（feature/release/hotfixes）。
8 “Feature branches”，起源于develop分支，最终也会归于develop分支。
9 “Feature branches”常用于开发一个独立的新功能，且其最终的结局必然只有两个，其一是合并入“develop”分支，其二是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里，而不应该是“中心版本库”中。 10 “Feature branches”起源于“develop”分支，实现方法是： git checkout-b myfeature develop 11 “Feature branches”最终也归于“develop”分支，实现方式是： git checkout devleopgit merge--no-ff myfeature（--no-ff，即not fast forward，其作用是：要求git merge即使在fast forward条件下也要产生一个新的merge commit）（此处，要求采用--no-ff的方式进行分支合并，其目的在于，希望保持原有“Feature branches”整个提交链的完整性）git branch-d myfeaturegit push origin develop
一个成功的Git分支模型
一个成功的Git分支模型 本文中我会展示一种开发模型，一年前该模型就已经被我用在所有的项目中（包括工作中的项目和私有项目），结果是非常成功的。我早就想为此写点东西，可直到现在才有时间。本文不会讲述任何项目的细节，只会涉及到分支策略和发布管理。
本文使用Git作为所有源码的版本控制工具。为什么是Git？
要全面了解Git与其它集中式版本控制系统相比的优劣，可以参考 这个页面。这方面的争论可谓是硝烟弥漫。作为一个开发者，所有 这些工具中我最钟情于Git。Git的的确确改变了人们考虑合并及分支的方式。在我之前所处的经典CVS/Subversion世界中，合并/ 分支总是被认为是有点可怕的事情（“小心合并冲突，丫会恶心到你”），因此你只应偶尔干这种事情。 但有了Git，这类事情就变得非常简单，分支及合并甚至被认为是 你日常版本控制操作的核心之一。例如，在CVS/Subversion 的书中，分支及合并往往在后面的章节才被介绍（针对高级用户），但在每一本Git的书中，该内容已经在前3章中介绍（基础）。 简单及易重复性带来的好处就是，分支及合并变得不再可怕。版本 控制工具本该帮助我们方便的进行和分支及合并操作。 简单介绍下工具后，让我们来看开发模型。我讲介绍的模型本质上 只是一组步骤，每个团队成员都必须遵循这些步骤以形成一个可靠 管理的软件开发过程。 去中心化但仍保持中心化 在这个分支模型中我们使用的，且被证实工作得很好的仓库配置， 其核心是一个中心―真理‖仓库。注意只有该仓库才被认为是中心库（由于Git是DVCS [分布式版本控制系统]，在技术层面没有中
gitlab多人协同工作
gitlab多人协同工作 2013-05-11 23:02:40| gitlab多人协同工作 gitlab----新颖的git服务器托管网站，开源免费。你可以在自己的公司或者开发团队搭建好一个。 gitlab的工作流程是 gitlab help中建议的工作流程是这样。如下图。 1 (1).开发成员拷贝管理员建立好的项目到自己本地。 (2).创建自己的分支。 (3).在自己的分支上写代码，并提交。 (4).推送到远程服务器，分支是自己的分支。 （分支的命名规则使用小驼峰式命名法。比如我是员工孙悟空，我就推送到孙悟空分支。分支的命名规则为开发人员姓名+所开发的功能。命名中不要使用特殊字符，不要使用点。例如孙悟空开发的分支，命名为swkFeature1） (5).在Commit页面上浏览分支。 (6).创建一个合并请求。 (7).团队的管理员或者领导者审查并且决定是否合并员工提交的分支到主分支上。 管理员在建好的项目中加入开发人员。 开发人员有相应的权限级别，分为Guest,Reporter,Developer,Master,等这几个角色，这几个角色的权限从低到高排列。 Developer能够推送和删除没有保护的分支，Master可以对没有保护和有保护的分支进行操作。如图1所示。 如下图
2 我们使用下面这个图示中的分支模型进行工作。 Git 的开发者都喜欢以这种方式来开展工作，在master 分支中保留完全稳定的代码，即已经发布或即将发布的代码。 与此同时，他们还有一个名为develop 专门用于后续的开发，或仅用于稳定性测试。当然并不是说一定要绝对稳定，不过一旦进入某种稳定状态， 便可以把它合并到master 里。还有在工作中，把开发任务分解为各个功能或者模块， 用topic（topic branch主题分支，有又成为feature branch特性分支），实现之后并测试稳定
Git详解之三 Git分支
Git分支 几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。 有人把Git的分支模型称为“必杀技特性”，而正是因为它，将Git从版本控制系统家族里区分出来。Git有何特别之处呢？Git的分支可谓是难以置信的轻量级，它的新建操作几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系统不同，Git鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。理解分支的概念并熟练运用后，你才会意识到为什么Git是一个如此强大而独特的工具，并从此真正改变你的开发方式。 3.1 何谓分支 为了理解Git分支的实现方式，我们需要回顾一下Git是如何储存数据的。或许你还记得第一章的内容，Git保存的不是文件差异或者变化量，而只是一系列文件快照。 在Git中提交时，会保存一个提交（commit）对象，该对象包含一个指向暂存内容快照的指针，包含本次提交的作者等相关附属信息，包含零个或多个指向该提交对象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先。 为直观起见，我们假设在工作目录中有三个文件，准备将它们暂存后提交。暂存操作会对每一个文件计算校验和（即第一章中提到的SHA-1 哈希字串），然后把当前版本的文件快照保存到Git仓库中（Git使用blob 类型的对象存储这些快照），并将校验和加入暂存区域：$ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' 当使用git commit新建一个提交对象前，Git会先计算每一个子目录（本例中就是项目根目录）的校验和，然后在Git仓库中将这些目录保存为树（tree）对象。之后Git创建的提交对象，除了包含相关提交信息以外，还包含着指向这个树对象（项目根目录）的指针，如此它就可以在将来需要的时候，重现此次快照的内容了。 现在，Git仓库中有五个对象：三个表示文件快照内容的blob 对象；一个记录着目录树内容及其中各个文件对应blob 对象索引的tree 对象；以及一个包含指向tree 对象（根目录）的索引和其他提交信息元数据的commit 对象。概念上来说，仓库中的各个对象保存的数据和相互关系看起来如图3-1 所示：
git管理规范
Git 使用规范流程以及支管理策略 团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。 否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。 下面是ThoughtBot 的Git使用规范流程。我从中学到了很多，推荐你也这样使用Git。 第一步：新建分支 首先，每次开发新功能，都应该新建一个单独的分支（这方面可以参考《Git分支管理策略》）。 # 获取主干最新代码 $ git checkout master $ git pull # 新建一个开发分支myfeature $ git checkout -b myfeature 第二步：提交分支commit 分支修改后，就可以提交commit了。
$ git add --all $ git status $ git commit --verbose git add 命令的all参数，表示保存所有变化（包括新建、修改和删除）。从Git 2.0开始，all是 git add 的默认参数，所以也可以用 git add . 代替。 git status 命令，用来查看发生变动的文件。 git commit 命令的verbose参数，会列出 diff 的结果。 第三步：撰写提交信息 提交commit时，必须给出完整扼要的提交信息，下面是一个范本。 Present-tense summary under 50 characters * More information about commit (under 72 characters). * More information about commit (under 72 characters). https://www.sodocs.net/doc/de1818119.html,/ticket/123 第一行是不超过50个字的提要，然后空一行，罗列出改动原因、主要变动、以及需要注意的问题。最后，提供对应的网址（比如Bug ticket）。 第四步：与主干同步 分支的开发过程中，要经常与主干保持同步。 $ git fetch origin $ git rebase origin/master 第五步：合并commit 分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。 那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。 $ git rebase -i origin/master git rebase命令的i参数表示互动（interactive），这时git会打开一个互动界面，进行下一步操作。