
线上环境 main/master 分支。
运行的都是稳定代码。
测试环境 feature分支。
日常需求开发中、你新增的代码都是基于master创建一个对应此需求的feature分支来开发。
上线
feature -> master
让master的代码中具备你在feature分支中新开发的代码。
流程
main分支:功能 1 2 3
feature分支:新增功能4
js
本地仓库 远程仓库
本地仓库的分支 对应有 远程仓库的 相同分支。
-
1、拉取"远程仓库"
master的最新代码【此时你idea里拉下来的代码就属于"本地仓库"的master代码】- 经常吧代码拉下来看看,这就拉下来了。
- 此时你需要开发功能。
-
2、基于"本地仓库"
master代码、创建一个"本地仓库"特性开发分支,命名为feature_add_4 -
3、然后就可以开始写代码了。在"本地仓库"的
feature_add_4分支中开发你的新代码。 -
4、将"本地仓库"的
faeture_add_4代码直接推送到远程对应该特性分支。 -
5、开始测试你的代码等等。
-
6、feature ---> release ---> master
例子
老大创仓库
平台选择,使用gitee作为平台,同名仓库有两种形态(1、本地 :类似于本地文件夹;2、远程: 网络,类似于网盘文件夹别人可以访问到,进行一个远程管理,暂放托管)。
创建仓库
老大创一个私人的仓库。
接着他会发一个邀请链接,邀请你进来共同开发这个项目。
配置ssh密钥
此时,我们要配置一个ssh密钥,以前很多仓库是用户名密码,现在几乎全部都是密钥。

ssh密钥就为了以后能远程动这个仓库,比如说pull、push等等操作。
拉取仓库
js
git clone git@gitee.com:zww0891/git-train.git
延伸自己的分支
自己创建一个分支,基于主分支创建一个自己的分支,这一步是方便代码隔离,不易出现一个地方出现bug后其余地方受牵连。
js
公司项目master
公司项目develop
员工A 员工B
如果直接在公司项目master上改代码万一出问题就很不好。所以说master是最终备份,develop是开发备份,我们各个员工分不同功能也是相同于一份一份这样子的备份。
比如说我是员工A,那么我开发完a功能,那我就要在公司项目develop上延伸出自己的分支,比如说feature分支,然后在这个feature分支上进行代码修改,开发功能完成,推到develop上的自己的feature分支,如果没问题或者pr代码检查过后没问题,然后merge到公司项目的develop分支,这个开发功能就完毕了。可以在公司项目develop上先在测试域名上测开发效果,确实真的没问题了,再最终合并到公司项目master分支。
同步别人的代码
别人的代码推到公司项目develop分支了,你切换到本地的develop分支,同步远程的develop最新代码,然后再合并到自己的开发分支。
这个时候咱的开发分支就能看到别人推的在远程develop分支上的新代码了。
就是Dao(二声)过来Dao(二声)过去。
就是同一个分支名字本地和远程的就是同步,不同分支名字本地和本地的就是合并的意思。
js
远程develop
| 同步
本地develop ------(切到feature分支,然后合并本地develop代码)------ 本地feature
解决冲突
比如说同事C也改了同一个文件比如说a.txt,并且,先于你提交到线上的develop分支。
你在本地也改了a.txt文件。
这个时候,
第一步:拉取最新的 develop 代码
bash
# 1.1 保存你当前的工作(确保所有修改已提交)
git checkout feature // 这一步可以不做,因为只是要确认我们当前是在功能修改的feature分支
git add .
git commit -m "feat: 功能开发"
# 1.2 切换到 develop 分支并拉取最新代码
git checkout develop
git pull origin develop
# 1.3 切换回 feature 分支
git checkout feature
第二步:合并最新代码 并 解决冲突
用merge
js
# 合并 develop 到 feature 分支
git merge develop // 这里也可以用git rebase develop变基
这个时候就会出现冲突,git这个时候会显示报错有冲突。
如果你没有图形界面工具看不出来就用命令行:
bash
git status
出来这个信息:
bash
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: example.py
然后就去看哪个文件冲突了,是谁跟你冲突了,跟他沟通一样用谁的。
bash
def some_function():
<<<<<<< HEAD
# 你的修改内容
return "your changes"
=======
# 同事A的修改内容
return "colleague A's changes"
>>>>>>> develop
手动解决冲突,保留你的还是他的,还是合并两者,改完之后:
bash
def some_function():
# 合并后的解决方案
# 可能保留你的逻辑,加入同事的功能
result = process_data()
return "merged solution: " + result
第三步:完成合并merge/变基rebase
merge合并的方式
bash
# 1、标记冲突已解决
git add a.py
# 2、继续完成合并
git commit
# Git 会自动生成合并并提交信息,你可以修改或直接保存
# 3、验证合并
git log --oneline --graph
第四步:终极
终极,有的公司要pr(pull request);有的公司可能不用pr,直接推送到远程的develop分支就可以了。我们先来说一下不用pr,直接推的方式:
不用pr 直接推
bash
# 1、切换到develop分支
git checkout develop
# 2、确保是最新代码
git pull origin develop
# 3、合并 feature 分支
git merge --no-ff feature // --no-ff 的意思是 --no-fast forward,作用是让合并历史更清晰,明确显示"这里曾经有过一个分支被合并进来"
# 4、推送到远程
git push origin develop
要pr 团队里有人审核代码
bash
# 1、推送 feature 分支到远程 merge的情况
git push origin feature
# 1、推送 feature 分支到远程 rebase的情况:如果之前推送过,现在需要强制推送(因为 rebase 改变了历史)
git push origin feature -- force-widht-lease
# 2、在代码平台创建 Merge Request / Pull Request // 这里面merge request 和 pull request 本质上是同一个概念,只是不同git平台使用的说法不同。
# - 源分支:feature
# - 目标分支:develop
# - 描述冲突解决情况
pr详细讲解
在代码平台创建 Merge Request / Pull Request // 这里面merge request 和 pull request 本质上是同一个概念,只是不同git平台使用的说法不同。
merge request: gitlab
pull request: github、gitee
都是一样的东西,只不过功能完全一样,都是请求将代码从一个分支合并到另一个分支。
在github的pr按钮:

可以理解为:想要把自己的代码合到对应分支里面的请求。(PR/MR 是发起从 源分支 到 目标分支 的合并请求的流程)
在平台创建:
markdown
- 在 GitLab 上:进入项目 -> 侧边栏 **Merge Requests** -> 点击 **New merge request**。
- 在 GitHub 上:进入项目 -> 点击 **Pull requests** 标签页 -> 点击 **New pull request**。
Pull Request / Merge Request 本身是代码平台的协作功能,不能直接用标准的 Git 命令行创建,但可以通过平台 API 或 CLI 工具来实现命令行创建。
标准的 Git 命令(git add, git commit, git push, git merge 等)只能处理本地仓库和远程仓库之间的同步,无法直接创建代码平台的 PR/MR,因为这是平台特有的协作功能
- 简单项目:直接使用平台网页界面创建 PR/MR
- 高效开发者 :安装并使用
gh或glabCLI 工具 - 团队自动化:考虑在 CI/CD 中自动创建或使用脚本
基本工作流
基本工作流是这样的:
bash
# 1. 切换到 feature 分支并推送
git checkout feature
git push origin feature
# 2. 现在 feature 分支已在远程,但还没有 PR/MR
# 你需要去平台网页界面创建,或者用下面的方法
平台官方CLI工具
GitHub CLI (gh) GitHub 提供了官方命令行工具,可以完全在终端创建和管理 PR:
bash
# 安装 GitHub CLI
# macOS: brew install gh
# Linux/Windows: 查看官方安装指南
# 登录认证
gh auth login
# 创建 PR(会自动推送到远程)
gh pr create \
--base develop \
--head feature \
--title "添加新功能" \
--body "详细描述更改内容,包括冲突解决情况..."
# 其他有用命令
gh pr list # 列出 PR
gh pr view --web # 在浏览器打开当前 PR
gh pr merge --squash # 合并 PR
GitLab CLI (glab) GitLab 也有类似的官方 CLI 工具:
bash
# 安装 GitLab CLI
# macOS: brew install glab
# 登录认证
glab auth login
# 创建 MR
glab mr create \
--source-branch feature \
--target-branch develop \
--title "添加新功能" \
--description "详细描述冲突解决情况..."
# 其他命令
glab mr list # 列出 MR
glab mr view --web # 在浏览器查看
平台API
可以用 curl 或任何 HTTP 客户端通过 API 创建:
GitHub API 示例
bash
# 使用 curl 创建 GitHub PR
curl -X POST \
-H "Authorization: token YOUR_GITHUB_TOKEN" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/用户名/仓库名/pulls \
-d '{
"title": "添加新功能",
"body": "详细描述,包括冲突解决情况...",
"head": "feature",
"base": "develop"
}'
GitLab API 示例
bash
# 使用 curl 创建 GitLab MR
curl -X POST \
-H "PRIVATE-TOKEN: YOUR_GITLAB_TOKEN" \
-H "Content-Type: application/json" \
https://gitlab.com/api/v4/projects/项目ID/merge_requests \
-d '{
"source_branch": "feature",
"target_branch": "develop",
"title": "添加新功能",
"description": "详细描述冲突解决情况..."
}'
脚本
可以创建便捷的 shell 函数:
bash
# 添加到 ~/.bashrc 或 ~/.zshrc
create-pr() {
local branch_name=$(git branch --show-current)
local title="Merge $branch_name to develop"
# GitHub 用户
gh pr create --base develop --head "$branch_name" --title "$title" --body "$1"
# 或者 GitLab 用户
# glab mr create --source-branch "$branch_name" --target-branch develop --title "$title" --description "$1"
}
# 使用
git add .
git commit -m "完成功能开发"
create-pr "解决了与develop分支的冲突:1. utils.js中的方法合并 2. 配置文件兼容性调整"
CI/CD
在 CI/CD 管道中自动创建 PR/MR
很多团队在自动化流程中创建 PR:
perl
# GitLab CI 示例
auto_create_mr:
stage: deploy
script:
- |
glab mr create \
--source-branch $CI_COMMIT_BRANCH \
--target-branch develop \
--title "Auto MR for $CI_COMMIT_BRANCH" \
--description "自动创建的合并请求"
rules:
- if: $CI_COMMIT_BRANCH =~ /^feature/
虽然 Git 本身不提供创建 PR/MR 的命令,但通过平台特定的 CLI 工具(gh/glab)或 API,你完全可以实现命令行创建工作流,这能大大提高效率,特别是在频繁创建 PR/MR 的情况下。