Git-GitHub-gitee分支合并详解

参考

1、什么是分支

在版本控制过程中，使用多条线同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也是指针的引用）

分支的好处

同时并行推进多个功能开发，提高开发效率
各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。
git commit -m "test branch hot_fix" a.txt

2、分支操作

2.1、概述

git中常见的分支包括以下几种分支，如图所示：

master分支。用于部署到生产环境，一般由 release 或 hotfix 分支合并，不允许直接在 master 分支上修改代码
release分支。预上线分支，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
develop分支。测试分支，一般用于测试环境中。始终保持最新完成以及 bug 修复后的代码。
- 若开发时间短，可直接在该分支进行开发、测试，在测试完成后直接推送到远程仓库。
- 若开发时间较长，则需在该分支上新建feature分支，待feature分支开发、测试完成后，推送到远程仓库，利用分支合并功能，合并该分支到develop分支上。
feature分支。该分支为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
hotfix分支。当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

总结：master和release分支不可直接更改，只能通过分支合并的方式来变更。日常开发一般在develop分支、deature分支和hotfix分支上工作。

2.2、分支开发应用场景

在实际的开发过程中，具体的流转流程如下所示：

使用git clone命令拉取远程仓库到本地
使用git checkout命令，切换到你要开发的分支。一般不在原分支中作修改，而在稳定的分支上新建分支进行操作
修bug，就在稳定的分支上新建fix分支
新功能，就在稳定的分支上新建feature分支。在新分支上进行编码和测试操作
使用git add 和 git commit命令来将所作的更改提交到本地仓库，每一次使用commit命令都会产生一条提交日志。
使用git push命令将分支推送到远程分支之上
待同事Review之后，将分支合并到稳定分支上

遇到新需求

遇到新需求时，即可在develop开发分支上直接编程、测试、推送，也可以新建分支完成该需求。具体分情况讨论，建议新开分支操作，避免与其他同事的提交代码产生冲突。如果新开分支，则一定要在稳定的分支上完成新建操作。
- 如果develop分支上所有的代码都是经过测试的稳定代码，那么可由该分支新建feature分支。
- 如果develop分支上存在尚未测试的代码，那么建议从master或者release分支上下载稳定的代码进而新建feature分支开发。

修复BUG

develop分支存在BUG。如果仅仅是该分支存在BUG，而master和release分支不存在bug，那么可直接在该分支新建fix分支，待修复bug后，将该分支合并到develop分支，然后删除该fix分支。
若master分支或release分支存在bug，那么需要回顾下develop分支是否有相同的bug。然后基于master分支新建fix分支，后将该fix分支分别合并到master分支和develop分支上。

总结：如果是新需求，那么在稳定的分支上新建feature分支，如果是线上bug，那么在线上环境所在分支上新建fix分支，待开发测试完成后，分别合并到master分支和develop分支上即可。

2.3、git commit 开发规范

参考：zhuanlan.zhihu.com/p/182553920

日常开发中的每一次代码变更，都需要利用git commit命令来记录变更，为了使代码变更清晰易懂，应该使用一定的规范来commit的内容。

推荐的git commit提交日志基本格式

<type>(<scope>): <subject>
复制代码

type [必须]：用于说明git commit的类别，比如是修复一个bug或增加一个新的feature ，只允许使用下面的标识。
- feat：新功能（feature）。
- fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
- docs：文档（documentation）。
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
- perf：优化相关，比如提升性能、体验。
- test：增加测试。
- chore：构建过程或辅助工具的变动。
- revert：回滚到上一个版本。
- merge：代码合并。
- sync：同步主线或分支的Bug。
scope [可选]
- 说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同
subject [必须]
- subject是commit目的的简短描述，不超过50个字符，可以是中文描述

commit 规范示例：

fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发
复制代码

2.4、基本命令

创建分支
- git branch [分支名]
查看分支
- git branch -v
切换分支
- git checkout [分支名]
合并分支
- 第一步：切换到接受修改的分支（被合并，增加新内容）上git checkout [被合并分支名]
- 第二步：执行merge 命令 git merge [有新内容的分支名]

2.5、操作演示

1、下面将展示一下上述几个命令的运用，首先，我们查看当前状态，会发现就是在主干分支上，再查看分支，目前就只有一个分支—主分支

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git status
On branch master
nothing to commit, working tree clean

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git branch -v
* master 031c707 删除文件b.txt

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$
复制代码

*代表当前所在分区

2、然后创建一个分支，取名hot_fix。再次查看分支，就会发现有两个分支，目前在主分支上(绿色的)。并且通过两个分支的指针都是031c707，发现现在两个分支都是同一个版本状态。

3、修改分支：在master分支上做修改，并添加至暂存区、提交到本地库，此时查看分支发现 hot-fix 分支并未做任何改变、master 分支已更新为最新一次提交的版本

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git add a.txt

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git commit -m "第四次提交" a.txt
[master 1bfddd4] 第四次提交
 1 file changed, 2 insertions(+), 1 deletion(-)

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git branch -v
  hot_fix 031c707 删除文件b.txt  #hot_fix分支还是和之前的一样
* master  1bfddd4 第四次提交   #主分支版本号已经是最新的一个

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$

复制代码

4、然后切换到分支hot_fix，再次查看分支，就会发现现在已经在hot_fix分支上了。并且查看此时 hot-fix 分支上的文件内容发现与 master 分支上的内容是不同的

两个分支内容对比：因为我们创建了一个hot_fix分支以后，才对master分支进行修改，所以hot_fix上的副本内容还是没变的。

#master分支
hello
hello
hello
hello
hello
yes
yes
青鸟飞鱼

#hot_fix分支
hello
hello
hello
hello
hello
yes
yes
复制代码

5、在 hot-fix 分支上对文件a.txt做修改，并添加到暂存区、提交到工作区

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (hot_fix)
$ vim a.txt

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (hot_fix)
$ git add a.txt

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (hot_fix)
$ git commit -m "hot_fix分支上的第一次修改" a.txt
[hot_fix fe424ee] hot_fix分支上的第一次修改
 1 file changed, 1 insertion(+), 1 deletion(-)

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (hot_fix)
$

复制代码

因为我们当前是在分支hot_fix上，又因为我们在当前分支上并对文件a.txt进行了修改，所以我们再次查看分支，会发现我们当前所在的分支hot_fix上的指针编号发生了改变。并且内容也和原来master分支修改后的内容是不一样的【各个分支的操作和master分支是一样的】

6、合并分支：然后这个分支任务完成了，我们想合并到主分支上，所以必须先切换到主分支上，然后使用合并命令将分支合并到主分支上

7、产生冲突

冲突产生的表现：后面状态为 MERGING

查看冲突文件a.txt

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master|MERGING)
$ cat a.txt
hello
hello
hello
hello
hello
yes
<<<<<<< HEAD
yes
青鸟飞鱼
=======
yesdddddddddd
>>>>>>> hot_fix

复制代码

冲突产生的原因：合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改【回想刚刚的操作好像真是】。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。　　

查看状态（检测到有文件有两处修改）

解决冲突

编辑有冲突的文件，删除特殊符号，决定要使用的内容，特殊符号：<<<<<<< HEAD 当前分支的代码 ======= 合并过来的代码 >>>>>>> hot-fix ，修改如下

重新提交到本地库

重新合并，然后我们因为在主分支上，展示该文件a.txt，会发现我们在分支hot_fix上修改的版本内容已经到了主分支上了。

这个内容只是在主分支上的额，hot分支上的内容还是以前的

2.6、解决合并分支后产生的冲突

什么时候会产生合并冲突？

假如说我们目前我们有两个分支master和hot_fix，目前两个分支的内容是一样的。

假设当想要合并的两个分支的同一文件中的同一行代码上有不同的修改，或者master分支修改了它的工作区的a.txt文件，并做了提交。而hot_fix分支也修改了它的工作区的a.txt文件，并做了提交。[并行修改：这里假设master分支修改的内容和hot_fix分支修改的内容不一样]。

这个时候，无论是master分支想要合并hot_fix分支，还是hot_fix分支想要合并master分支，都会合并冲突。在这样的情况下，Git 会询问你想要保留哪种选择？

演示：

略：上面操作已经演示了

解决冲突

冲突是因为我们两个不同版本合并时，两个版本都有的文件被修改了。这个时候就需要两版本的作者，讨论一下，需要怎么做。

<<<<<< HEAD到=======之间的内容就是当前分支的内容【因为有HEAD,HEAD指向当前内容】
========到>>>>>>> master之间的内容是另外一个分支的内容。
所以git不知道你要提交的是哪一个

如何解决这个冲突？

首先，肯定手动是要删除提示信息，这三行。

同时根据两个版本作者讨论的结果，对文件内容进行修改到满意程度。

最后再次提交。

演示冲突解决：假设我们修改的结果是对这两个修改都进行保留。

删除特殊符号，保留想要保留的内容
提交解决合并冲突 : 注意commit文件不能带文件名

2.7、补充：项目分叉历史

你可以简单地使用 git log 命令查看分叉历史。运行 git log --oneline --decorate --graph --all ，它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git log --oneline --decorate --graph --all
*   8820c2e (HEAD -> master) 解决合并冲突后的文件
|\
| * fe424ee (hot_fix) hot_fix分支上的第一次修改
* | 1bfddd4 第四次提交
|/
* 031c707 删除文件b.txt
* ff39c2b 新创建的一个文件
* db30392 （练习的第一次提交）
* bc34445 第一次提交

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$
复制代码

2.8、补充：git rebase 变基操作

使用场景一：不同分支进行rebase操作

开发者在feature分支上开发新功能，而此时master分支上同事推送了新的代码，因此如果feature分支需要获得master分支的代码只有两种形式。

git merge。将master分支的变更合并到当前的feature分支上，这大会产生合并的结，使你feature分支的提交不清晰。不推荐
git rebase。该命令会将master分支的变更同步到本地，同时，修改你feature分支的基础commit。

总结：在进行分支合并时，feature分支合并到develop分支/ master分支时，建议使用git merge。而master分支/develop分支的变更合并到feature分支时，推荐使用git rebase。这会使提交历史更清晰。

使用场景二：同一分支进行rebase操作，实现压缩commit

日常在feature开发工作中，往往会稍作一点变更就git commit提交该变更，然而当该feature分支合并到develop分支时，会导致大量的develop的分支历史及其不清晰。因此，需要压缩commit，将所有的commit合并为一条，然后再向develop分支提出分支合并请求。

git rebase -i HEAD~3    #整理HEAD附近3条的commit记录
git rebase -i $COMMIT_ID #整理指定COMMIT_ID之前的所有commit记录
#上述命令会进入到一个交互式的编辑界面
# 将除第一条以外的commit都改为squash即可将所有的commit合并到第一条记录中。
复制代码

另：如果当前commit历史较为复杂，并非一条直线时，该命令将会产生冲突，无法达到合并commit的结果。故建议下游更新上游代码时，使用git pull --rebase，或者 git fetch + git rebase 的操作，使下游分支提交历史较为清晰。不然在合并commit时会遇到麻烦。

3、Git基本原理

3.1、Blob对象

3.2、Git 提交对象

暂存操作（ add ）会为每一个文件使用 SHA-1 哈希算法计算校验和，然后会把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 对象来保存它们），最终将校验和加入到暂存区域等待提交。右上角的 5b1d3 就是校验和的一部分。

当进行提交操作（commit）时，Git 会先计算每一个子目录（本例中只有项目根目录）的校验和，然后在 Git 仓库中这些校验和保存为树对象。随后，Git 便会创建一个提交对象，它除了包含上面提到的那些信息外，还包含指向这个树对象（项目根目录）的指针。如此一来，Git 就可以在需要的时候重现此次保存的快照。

Blob 对象保存着文件快照、树对象记录着目录结构和 blob 对象索引，提交对象包含着指向前述树对象的指针和所有提交信息。上图中因为是首次提交，索引提交对象中没有 parent 指针。

可以从上图发现，非首次提交的提交对象都会有一个 parent 指针。

4、Git团队协作机制

4.1、团队内协作模式

令狐冲队友将从远程库克隆下来的代码进行修改，然后想要推送到远程库，就必须进行push操作，但是前提是它必须有岳不群团队赋予的权限，让他加入团队，令狐冲才能进行push操作。然后岳不群团队就能从远程库进行pull操作将令狐冲推送的代码给拉取下来，更新自己的本地库

4.2、跨团队协作模式

东方不败作为另外一个团队的人，岳不群团队想要请东方不败帮着修改一下代码，于是东方不败就将岳不群的远程库给fork到自己的远程库里面，然后clone到自己的本地库里面，进行修改、提交、push推送到自己的远程库里面，然后东方不败发起请求pull request给岳不群，然后岳不群通过审核修改的代码，然后执行merge合并操作，然后岳不群团队就能从自己的远程库进行pull操作将东方不败推送的代码给拉取下来，更新自己的本地库

5、GitHub操作

GitHub 网址：github.com/

5.1、创建远程仓库

5.2、远程仓库操作

常用命令

补充：

【fetch】：取回

5.2.1、创建远程仓库别名

因为远程仓库地址连接太长了，记不住，以后pull拉取操作直接使用别名

基本语法

git remote -v 查看当前所有远程地址别名
git remote add 别名 远程地址  #添加别名
复制代码

实操案例

远程库连接地址：

5.2.2、推送本地分支(本地库代码)到远程仓库

基本语法

git push 别名 分支
复制代码

实操案例

本地库中内容如下：

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ cat a.txt
hello
hello
hello
hello
hello
yes
yes
青鸟飞鱼
yesdddddddddd
复制代码

推送：第一次推送会叫你登录github

执行命令git push 别名分支，推送成功：建议使用热点试一下

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$ git push git-Lemon master
Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 8 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (19/19), 1.62 KiB | 184.00 KiB/s, done.
Total 19 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), done.
To https://github.com/LanMeiX/git-workspace.git
 * [new branch]      master -> master

lemon@LAPTOP-DU0LC6FO MINGW64 /e/git-workspace (master)
$

复制代码

刷新github页面：此时已经成功推送到远程库了

并且双击该文件可以查看，并且提供了修改操作

此时发现有个问题：提交代码到仓库，显示别人的头像和名称，这是因为在设置全局签名的时候出了问题，填了别人的邮箱，解决如下

#打开git 命令模板 输入以下命令（用户名和邮箱都要改）
git config --global user.name "这里写用户名"
git config --global user.email "这里写邮箱"
复制代码

再次推送尝试一下(要执行add acommit操作)，这下就改过来了

5.2.3、拉取远程仓库到本地

基本语法

git pull 远程地址 分支
复制代码

实操案例

我在网页端直接修改远程库里面的代码，然后提交

然后我现在要更新本地库代码，则需要将远程库修改的拉取到本地，如下

5.2.4、克隆远程库到自己本地

假设小明(还未加入我这个团队)想克隆我这个团队远程仓库的的一些东西，如下，新建一个小明的本地库

在小明的本地库中git bash，想克隆，必须知道我的远程仓库的地址，如下，这个地址就是远程仓库的地址

开始执行clone命令进行克隆

克隆完毕以后，这个时候，查看小明的本地库，发现将我的远程库里面的内容一抹一样直接克隆下来了

查看相应的信息，对方只要给自己远程库起了别名，我们克隆下来的也有别名，并且也会初始化好，发现克隆后自动起别名origin

小结：clone 会做如下操作。1、拉取代码。2、初始化本地仓库。3、创建别名origin

5.2.5、邀请加入团队

小明克隆下来以后，进行里面的内容的修改，add commit后，想要push到远程库，必须要加入我这个团队具有权限，才能push操作，步骤如下

1）选择邀请合作者

2）填入想要合作的人

3）复制邀请函地址并通过微信钉钉等方式发送给该用户，复制内容如下：

4）在小明自己的github账号中的地址栏复制收到邀请的链接，点击接受邀请

5）在成功之后可以在小明自己的这个账号上看到我这个 git-Lemon 的远程仓库。

6 ）小明此时可以修改内容，执行add等操作后并 push 到远程仓库。

7）回到我的 GitHub 远程仓库中可以看到，最后一次是小明提交的

然后就可以拉取了pull 更新我的本地库代码

补充：另外一种pull的方式

pull=fetch+merge

git fetch [远程库地址别名][远程分支名]
git merge [远程库地址别名/远程分支名]
git pull [远程库地址别名][远程分支名]

步骤：

执行git fetch 别名 master将远程库中的东西抓取下来，并查看，发现本地库文件还是没变
再次执行git merge origin/master，这样合并完以后，本地就有新的内容了
补充：为啥要将pull分开操作，因为这样的话，我们在执行完fetch拉取操作完后，我们还可以查看远程库主分支提交的内容，再辨别有没有什么问题后确认是否合并，比如

5.2.6、跨团队协作

在这里插入图片描述

5.3、SSH免密登录

由于win10系统有凭据管理器，所以在使用Https地址的方式推送的时候不需要每次都登录GitHub，但是在其他windows的系统中不是这样【需要每次输入密码】，这时我们可以使用SSH的方式推送(push)，并设置SSH免密登录(一台机器只能为一个账号设置免密登录)，这样就免去了每次推送都登录的麻烦。我们可以看到远程仓库中还有一个 SSH 的地址，因此我们也可以使用 SSH 进行访问。

具体操作如下：

1、进入到用户的家目录：

cd ~
复制代码

2、如果以前创建过SSH免密登录，需要将其删除：

rm -r .ssh/
复制代码

3、生成.ssh目录：执行命令后一路回车

$ ssh-keygen -t rsa -C atguigu2018ybuq@aliyun.com
复制代码

4、进入到生成的.ssh目录，可以看到生成的文件：

5、查看id_rsa.pub文件，并将其中的内容复制出来，以备使用：

6、将5中复制下来的内容粘贴到GitHub的SSH & GPG keys中：复制 id_rsa.pub 文件内容，登录 GitHub，点击用户头像→Settings→SSH and GPG keys

在这里插入图片描述

7、最后点击Add SSH key：

8、回到工作区去测试：在Git的bash客户端创建SSH地址的别名映射(不能使用Https地址的别名映射推送)，随便修改提交一个文件到本地库，随后步骤如下

①新建一个ssh远程地址的别名：

git remote add ssh远程库别名 ssh远程库地址
复制代码

ssh远程库地址查看方式如下：

②查看别名映射：

8、使用ssh的别名映射推送：推送不需要密码账户

6、国内代码托管中心-码云

创建远程库和其他操作和github是一样的：

最后根据需求选择分支模型，然后点击创建按钮

远程库创建好以后，就可以看到HTTPS和SSH的链接

7、协同开发常见冲突

7.1、不同人修改了不同的文件

a.令狐冲，岳不群分别从远端拉取了相同分支到自己的本地库
b.令狐冲修改了本地库上的main.cpp文件后提交到远端，岳不群修改fun.cpp文件提交远端时会报如下错误

解决办法：

岳不群提交前，先执行git pull指令，弹出文件直接wq保存即可
再推送到远端git push origin dev,这时将不报错

7.2、不同人修改了同一文件不同区域

a.令狐冲，岳不群分别从远端拉取了相同分支到自己的本地库
b.令狐冲修改jianpu.txt文件的第一行内容后提交到远端，随后岳不群也修改了jianpu.txt文件的第二行内容后推送到远端，会报如下错误

解决办法：

岳不群推送前，先执行git pull指令，弹出文件直接wq保存即可
再推送到远端git push origin dev,这时将不报错

7.3、不同人修改了同一文件的同一区域

a.令狐冲，岳不群分别从远端拉取了相同分支到自己的本地库

b.令狐冲修改jianpu.txt文件的第二行内容后推送到远端，随后岳不群也修改了jianpu.txt文件的第二行内容后推送到远端，就会报如下错误

原因：因为在令狐冲推送完毕后，远程库就更新了，岳不群必须拿到最新的版本才行，必须先拉取

解决办法：岳不群执行git pull指令，这时git会把远端的jianpu.txt文件与本地仓库的jianpu.txt文件进行merge，提示MERGING 状态，由于是同一区域需要手动进行merge，这部分上面讲过，即冲突解决，然后提交到本地仓库
和远端仓库

8、实际开发场景如何应用git

注意：

1、将团队的代码库下载到本地，此处分为两种场景。

对团队的代码库有开发权限，那么可直接使用`git clone命令将代码库下载到本地
对团队的代码库没有开发权限，那么需要先fork团队的仓库到自己的仓库中，接着克隆自己的仓库到本地

2、在本地进行编码和测试工作

新建分支。在稳定分支上（develop分支/master分支/release分支，具体问导师）新建开发分支(feature分支/fix分支)。–> git checkout
在新建分支上进行编码和单元测试工作。–> git add && git commit
将单元测试后的代码分支推送到远程仓库。–> git push
- 如果出现了冲突，需要先用git fetch命令，将远程仓库拉下来
- 使用git merge命令合并冲突
- 使用git push 再次推送。
- 也可直接git pull(直接进行了git fetch 和git merge操作)，然后git push。
在github上发起PR/gitlab上发起MR，请求别人review自己的代码，然后将自己的代码合并到测试分支(develop分支)上。
将develop分支的代码应用到测试环境中，如果有问题则回退到第2步继续进行开发
将develop分支测试稳定的代码，提交PR/MR到稳定分支(master/release)上，进而在生产环境中应用该代码。

3、在发起PR/MR时，要求提交历史仅有1个

使用git rebase命令
使用git reset命令

4、开发进行一半，需要同步远端主分支的最新代码

git status 查看当前项目的状态，如果有未保存的修改，就git add . 和 git commit -m $message保存下来
git pull –rebase origin develop 使用这个指令将远端的主分支以 rebase 的形式 “合进”当前分支
也可使用git fetch + git rebase的形式
git log 查看当前分支下的 commit message 是否符合预期

总结：下游需要上游代码，使用git rebase获取上游最新代码，进而保证下游分支提交历史清晰、简洁。

总体步骤

先把master主分支上的代码与远程仓库同步到最新版本。直接从远程仓库pull下来
在本地创建并切换到工作分支，创建完成后会自动切换到该分支（这时候master/work分支的内容是相同的。）
编写代码。
完成后，add commit到work分支
将主分支从远程仓库pull最新的版本下来。
将工作分支合并到主分支
- 先切换到主分支master
- 选中要合并的分支work，点击merge
- 如果有冲突，则需要手动解决冲突
这时候所有在work分支上做得修改就会合并到主分支上。
最后就可以push到远程仓库上了。

关于分支切换的两个注意点

分支切换一定要先add/commit当前分支上的修改，然后如果在修改完代码后没有提交，就想切换，idea会提示是否进行smart checkou，如果你点击yes你就完完了，idea会把当代分支上的修改，保存到你要切换的另一个分支上。这样一样就乱套了。
如果当前工作分支上有很多bug不想提交，那么你可以先隐藏当前工作分支上的修改，stash（隐藏），然后切换到另一个分支上，那么下次你又切换回工作分支的时候，你可以通过unstash把修改的代码重新显示出来。

文章版权归作者所有，未经允许请勿转载。

THE END

后端

网易/抑云音乐v7.1.8破解版晚上等你们哭就完事了

安卓跑车声浪模拟器v1.0.4

PHPReactor样式属性HTML注入漏洞

IBM ThinkVantage TPM服务HTTP信息包缓冲区溢出漏洞

React Hook 学习笔记

Apple QuickTime ‘QuickTimePlayer.dll’缓冲区溢出漏洞

Git-GitHub-gitee分支合并详解

Git-GitHub-gitee分支合并详解

1、什么是分支

2、分支操作

2.1、概述

2.2、分支开发应用场景

2.3、git commit 开发规范

2.4、基本命令

2.5、操作演示

2.6、解决合并分支后产生的冲突

2.7、补充：项目分叉历史

2.8、补充：git rebase 变基操作

3、Git基本原理

3.1、Blob对象

3.2、Git 提交对象

4、Git团队协作机制

4.1、团队内协作模式

4.2、跨团队协作模式

5、GitHub操作

5.1、创建远程仓库

5.2、远程仓库操作

5.2.1、创建远程仓库别名

5.2.2、推送本地分支(本地库代码)到远程仓库

5.2.3、拉取远程仓库到本地

5.2.4、克隆远程库到自己本地

5.2.5、邀请加入团队

5.2.6、跨团队协作

5.3、SSH免密登录

6、国内代码托管中心-码云

7、协同开发常见冲突

7.1、不同人修改了不同的文件

7.2、不同人修改了同一文件不同区域

7.3、不同人修改了同一文件的同一区域

8、实际开发场景如何应用git

网易/抑云音乐v7.1.8破解版 晚上等你们哭就完事了

安卓跑车声浪模拟器v1.0.4

PHPReactor样式属性HTML注入漏洞

IBM ThinkVantage TPM服务HTTP信息包缓冲区溢出漏洞

React Hook 学习笔记

Apple QuickTime ‘QuickTimePlayer.dll’缓冲区溢出漏洞

Git-GitHub-gitee分支合并详解

Git-GitHub-gitee分支合并详解

1、什么是分支

2、分支操作

2.1、概述

2.2、分支开发应用场景

2.3、git commit 开发规范

2.4、基本命令

2.5、操作演示

2.6、解决合并分支后产生的冲突

2.7、补充：项目分叉历史

2.8、补充：git rebase 变基操作

3、Git基本原理

3.1、Blob对象

3.2、Git 提交对象

4、Git团队协作机制

4.1、团队内协作模式

4.2、跨团队协作模式

5、GitHub操作

5.1、创建远程仓库

5.2、远程仓库操作

5.2.1、创建远程仓库别名

5.2.2、推送本地分支(本地库代码)到远程仓库

5.2.3、拉取远程仓库到本地

5.2.4、克隆远程库到自己本地

5.2.5、邀请加入团队

5.2.6、跨团队协作

5.3、SSH免密登录

6、国内代码托管中心-码云

7、协同开发常见冲突

7.1、不同人修改了不同的文件

7.2、不同人修改了同一文件不同区域

7.3、不同人修改了同一文件的同一区域

8、实际开发场景如何应用git

网易/抑云音乐v7.1.8破解版晚上等你们哭就完事了