在开发过程中，git rebase 和 git merge 都是常见的代码合并命令。它们都能够将分支代码合并到主分支，并且都有各自的优缺点。
📷 分支说明 main 分支 发布分支。 包含最新稳定版本，每个版本都是该分支上的一个tag。 长期分支。 保护分支，非Maintainer成员不能直接提交，只能从其他分支合并。 📷 develop 分支 主开发分支。 新功能或 bug 修复分支都从这里拉取和提合并请求。 长期分支。 保护分支，非Maintainer成员不能直接提交，只能从其他分支合并。 建议设置为仓库默认分支 📷 feature 分支 新功能特性分支。 从develop分支拉取，开
在GIT中，分支（Branch）管理是一项重要的功能，它允许你在不影响主要项目代码的情况下，进行独立的开发工作或实验性工作。以下是如何创建和切换分支的步骤：
来源：https://www.cnblogs.com/fangsmile/p/11535302.html
Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作。
1.从master拉一个新的release分支 例如:release*** 2.将feature/***分支或者hotfix/***分支合并到release***分支 3.发布之前问一下群里，有没有其他人当天也发布代码（协调好时间顺序，务必上一个release***代码合并master后，再发布下一个） 4.发布之前再将master代码合并到release***分支（防止发布前一刻master代码有变化） 5.在jenkins里发布release***上线 6.将release***合并到master（在发布当天下班前）
掌握Git是一个程序员的基本必备技能，特别是多人合作中，如何进行分支管理开发，如何与他人一同协作，应对复杂的需求进度需求，我们如何通过git代码管理我们的项目，变得尤为重要，本文是一篇笔者关于git一些总笔记结，希望看完在项目中有所帮助。
Svn中也有分支管理，但是很low，Git的分支管理非常强大，本文先不去说分支管理内部到底怎么做的，我们先来看看Git中最基本的分支管理操作。 本文是Git系列的第四篇，了解前面的文章有助于更好的理解本文。 ---- 分支的必要性 小伙伴们都知道，我们在完成一个项目时，不可能是“单线程”开发的，很多时候任务是并行的，举个栗子：项目2.0版本上线了，现在要着手开发3.0版本，同时2.0版本可能还有一些bug需要修复，这些bug修复之后我们可能还会发2.1，2.2，2.3这些版本，我们不可能等所有bug都修复完
如非特殊说明，所有产品的版本号将遵循 主版本.次版本.BuildNumber 的规则。
新建项目 项目负责人在项目组下面新建项目（以下简称‘主项目’），所有参与该项目开发的人员，必须fork此项目到自己的工程（以下简称‘fork项目’），然后进行开发。 主项目分支 主项目建立hotfix、release、dev、test四个分支。 dev分支 dev是开发分支，开发分支是更新最频繁的分支，开发人员正在开发的代码都必须且只能提交Merge Request（以下简称MR）到这个分支。 test分支 test是测试分支，用于发布测试环境。项目完成一个或多个功能点或者用户故事时，由负责测试版本
在Git中，高级分支策略是为了有效地管理和整合分支而设计的。其中一个关键方面是分支合并策略，它定义了如何将一个分支的更改合并到另一个分支。以下是几种常见的分支合并策略：
作者:fbysss msn:jameslastchina@hotmail.com blog:blog.csdn.net/fbysss 声明：本文由fbysss原创，转载请注明出处 关键字：svn分支合并
master 生产主分支，发布到生产环境使用这个分支，由hotfix或者release分支合并过来，不直接提交代码。 release 预发布分支, 基于feature分支合并到develop之后 , 从develop分支克隆，测试完成后合并到master并tag打上版本号，同时也合并到develop。 develop 主开发分支, 基于master分支克隆，由feature分支合并过来，一般不直接提交代码。 feature 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发，可能同时存在多个。 hotfix 补丁分支, 基于master分支克隆 , 主要用于对线上的版本进行BUG修复，完成后合并到master分支和develop分支。
从接触编程就开始使用 Git 进行代码管理，先是自己玩 Github，又在工作中使用 Gitlab，虽然使用时间挺长，可是也只进行一些常用操作，如推拉代码、提交、合并等，更复杂的操作没有使用过，看过的教程也逐渐淡忘了，有些对不起 Linus 大神。
目前项目已逐步从svn移步到git开发模式，其中也针对git统一协议了适合git的开发规范， 最重要一点就是分支模型的，为了规范开发，不直接在主干上修改代码，一切代码都提交至分支dev，然后再由分支合并到主干master。 首先保证每个仓库下有以下两个常驻分支（永远不删除的分支）： master：主干分支，始终保持跟外网服务器一致，只用于外网发布，这样就可以保证文件不会带出去的风险； dev：基于master创建，用于开发新功能和新需求的分支。
关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支
解决 Git 合并冲突是每个开发人员都讨厌的事情之一，尤其是当你准备进行生产环境部署时！
如果当前指针指向的是 master 分支，那么下面代码就是将 dev 分支合并到 master 分支
05.Git分支管理 Git 分支管理 几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。 有人把 Git 的分支模型称为"必杀技
在 Git 中，如果要合并两个分支，而这两个分支的历史记录不相交，就会出现错误：fatal: refusing to merge unrelated histories。
进入Members选项卡添加成员到Groups组，添加信息包括（成员邮箱、权限、到期时间）权限分为五种，分别代表五种不同权限。
git 流程模式有两种：一种是Git flow工作流，一种是Github flow工作流。
在开发中，遇到这样的情况怎么办？ 网站已有支付宝在线支付功能，要添加"微信支付"，修改了两个文件，wechat.php、pay.php。 刚做到一半，突然有个紧急bug：支付宝支付后不能修改订单状态。你需要立即马上修改这个bug，需要修改的文件是，ali.php、pay.php。 问题是，pay.php文件，已经被你修改了过，而且尚未完成，直接在此基础上改，肯定有问题。把pay.php倒回去？那我之前的工作白费了。 此时你肯定会想：在做"微信支付"时，能否把仓库复制一份，不影响原仓库的内容，修改完毕后，再把副本上的修改合并过去。 好的，这时你已经有了分支的思想。 前面见过的master，即是代码的主干分支。 事实上，在实际的开发中，往往不会直接修改和提交到master分支上，而是创建一个dev分支，在dev分支上，修改测试，再把dev分支合并到master上。 如果有了分支，刚才的难题就好解决了。 在做"微信支付"时，我们创建一个wechat分支，把wechat分支commit，此时，master分支内容不会改变，因为分支不同。 当遇到紧急bug时，创建一个AliBug分支，修复bug后，把AliBug分支合并到master分支上。 再次从容切换到wechat分支上，接着开发"微信支付"功能，开发完毕后，把wechat分支合并到master分支上。
Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master
在要合并的分支右键点击Merge——》点击Merge to Working Tree
也就是说，使用GitLab进行Code Review就是在分支合并环节发起Merge Request，然后Code Review完成后将代码合并到目标分支。
VV采用标准的Git flow，下面将从工作流图与抽象模型两个方面，来描述与规范 Git flow。
此时我们提交的只是在test分支,在master主分支上,其实并没有,所以我们还需要将test分支合并到master主分支上.
关于Git Flow 工作流，我想已经是老生常谈的话题了，但是今天我不得不来重温一下 Git Flow 工作流。当我看的代码厂库的时候，我已经开始怀疑人生。乱七八糟的分支，五花八门的提交信息，各种各样的分支名称，没有 Develop 分支，没有 Release，也没有 Hotfix。因此我想我应该好好温习一遍 Git Flow 工作流，来改善一下厂库现状。
许多公司的开发团队都采用 Git 来做代码版本控制。如何有效地协同开发人员在开发、测试、上线各个环节的工作，可能都有各自的流程与规范。本文就分享作者一直沿用的团队项目 Git 分支管理规范，希望给有缘阅读的人加以参考，如果有更好的实践，也欢迎探讨、交流，谢谢！
而且众多 Git 命令当中，Git rebase 和 Git merge 都是可以将一个分支的修改合并到当前分支当中去。
在Git的分支合并过程中支持方式，一种是在本地将source branch 合并到 target branch，然后再切换到target branch后将target branch push到远端target branch。另外一种是将本地的source branch push到远端的source branch，然后在gitlab上提交一个将source branch 合并到 target branch的merge request。那么为了能够到达我们强制的CodeReview卡点，我们将master branch（也就是生产发布分支）、release branch（也就是提测分支）进行保护，不能接受直接的push request，只能通过提交merge request，并有架构师或者技术负责人进行CodeReview通过后，完成Merge。那么如何完成Git的分支保护呢？
https://blog.csdn.net/su1573/article/details/91990437
本地的 master 和远程分支 origin/master 是关联起来的，origin/master 就对应着远程仓库的 master分支
每天如何操作git 一般习惯是什么样的,一个模块或一个页面或一个功能为单位 git add git commit 多次添加多次提交。 而git Push 或pull 一般为早晨 和中午 或下班前 提交，这个操作意味着你要提到远程仓库，让别人看到，让是不管电脑坏不坏，公司仓库代码是有的。 中间如果要上线，或别人需要，那push 也是可以的，其他就不要频繁操作，那样别人会不断的更新。 以下是一下常用的命令。分享一下 git 有github 这个是开源的，个人的项目可以被别人看见的，公司的项目一定不能公开放上去，要有法律责任的 bitbucket.org coding gitee 等这些都是做私有仓库的。还有就是自己搭建一下，其实也挺方便的。本地文件上传线上 git仓库
分支是指在主干道上分支的支线，可以前往不同的地方，也可以到达相同的终点(只是实现的路线不同)。Git指向团队开发中的个体，各开发者可以有自己的分支，开发时不会影响其他分支的开发进度。分支完成阶段性工作后，可以整合到上级分支。(功能开发完成，调试OK )这个上级分支一般是指Git默认创建的Master分支，这个分支不参与开发，只用于项目的管理、维护、集成、发布。
git 通过保存一系列不同时刻的快照，来记录文件在不同时刻的差异。git 的分支，本质上是指向提交对象的可变指针。git 的默认分支名是 master。在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。 master 分支会在每次提交时自动向前移动。
在我们每次的提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
高效的持续交付体系，必定需要一个合适的代码分支策略。采用不同的代码分支策略，意味着实施不同的代码集成与发布流程，这会影响整个研发团队每日的协作方式，因此研发团队通常需要很认真地选择自己的策略。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
