Git - 在公司中,使用 git 的流程是什么?遇到冲突怎么办?

本文详细介绍了公司在日常工作中如何使用Git,包括设置用户签名、创建分支、提交代码到远程仓库、创建PR和处理代码冲突的步骤。特别强调了新员工应遵循的规则和注意事项。

目录

一、公司中 git 的使用流程

1.1、设置用户签名

1.2、创建分支,提交代码到远程仓库

1.3、创建 pr,code review

1.4、意外情况:分支冲突

1.5、分支冲突另一种解决办法

1.6、分支冲突最好的解决办法(最推荐!!!)


一、公司中 git 的使用流程


1.1、设置用户签名

刚进公司,肯定是先初始化个人的用户签名啦~

用户名一般是你的 "花名" .

邮箱就是公司给你的邮箱.

git config --global user.name "用户名"
git config --global user.email 邮箱

配置权限:

1. local(优先级最高):默认,只影响本地;

2. global (优先级中等) :影响当前用户的git仓库;

3. system (优先级最低) :印象到全系统的git仓库;

注意:首次下载git一定要进行设置,否则后续提交代码会出错;这里的邮箱不一定需要真实邮箱,可以是一个虚拟邮箱;

执行之后就可以在用户目录下看到这个文件:

1.2、创建分支,提交代码到远程仓库

a)写完代码之后,就可以提交代码啦~

注意:对于实习生来说,push 的时候不能在 master 主分支上,而是要自己先创建一个分支,然后 push 自己的分支!

因此建议写完代码之后,首先就是要创建分支并切换.

git checkout -b feature/xxx

Ps: 分支名以 "feature/" 开头,后面的内容自定义即可.

b)接下来就是以下一顿操作

git add .

git commit -m "feat:xxx" .

git push origin feature/xxx

Ps:提交的信息以  "feat:" 开头,后面的内容有意义即可

c)不出意外的话(没有分支冲突,不过作为实习生的你,自己的分支 push 一般是不会遇到滴),因该是以下情况

1.3、创建 pr,code review

a)此时就可以去到代码仓库中新建一个 pr

b)选择你要向哪个分支上去合并,以及评审人(一般就是你的 Monter)

c)选择你的评审人

d)之后就可以将此页面的链接发送给你的 Mentor 啦,他就会对你的代码进行 code review...  指出哪里有问题,如果没问题的话,你的导师就会直接给你 merge 了.

Ps:下面这一步,在你不是正式工之前,一般都是由你的 Mentor 来完成的,

之后你就可以去 预发 啦.

1.4、意外情况:分支冲突

a)这天,你兴致勃勃的敲完代码,并且 push 完后,准备 pr,却发现如下情况:

这种情况就是因为你在你的分支上写代码之前,有其他人提交了代码到 master 分支上,导致你本地的代码和远程仓库的代码不一致,此时你再去编辑本地的代码(你 push 的文件正好是别人在远程仓库上已经修改过的文件),然后 push,就会出现以上这种情况.

因为 git 可不知道你是要保留远程仓库上的代码,还是保留你的代码,还是都保留...

b)莫慌莫慌,此时你只需要通过 pull 再拉取一下你要合并的那个分支的到你自己的分支上即可

例如,我当前是 feature/xxx 分支,需要向 master 分支合并,但是遇到了上述冲突,因此你只需要在 feature/xxx 分支上,拉取一下 master 分支的代码,如下:

c)此时你再去查看你之前 push 的文件,就可以选择保留谁的代码啦

比如我两个都要,那么删掉提示信息即可.

d)此时你就可以继续,执行以下一套操作来提交代码啦~

e)这个时候,你再刷新 pr 的页面,就会发现冲突已经解决了~

1.5、分支冲突另一种解决办法

当你在 feature/kang 分支上面做了修改,然后 push 上去之后发现冲突了.

a)首先 git pull 拉取最新的 master


b)然后切换到自己的分支上.

c)然后将 master 分支合并到自己的分支上

d)接着通过 git status 就可以看到自己的冲突文件了

解决这些冲突

e)修改完成之后,提交即可

git add .
git commit -m 'feat: search'
git push origin feature/kang

f)冲突就解决了~

1.6、分支冲突最好的解决办法(最推荐!!!)

1)git pull --rebase

例如我在本地 feature/yikang/fix 上工作(E),同时,远程的 master 上有新的提交(C 和 D).

远程 master: A -- B -- C -- D
本地 feature/yikang/fix: A -- B -- E

然后执行 git pull --rebase origin master ,会先拉取远程 master 上的 C 和 D 提交,然后将 E 放到 D 之后,如下:

本地 feature/yikang/fix: A -- B -- C -- D -- E

然后解决冲突就完事了~

2) git rebase master 

例如我在本地 feature/yikang/fix 上工作(E),同时,本地的 master 上有之前的提交(C 和 D).

本地 master: A -- B -- C -- D
本地 feature/yikang/fix: A -- B -- E

然后执行  git rebase master ,会把本地 master 上的 C 和 D 拉过来,接着将 feature/yikang/fix 上的 E,放到 D 之后,如下:

本地 feature/yikang/fix: A -- B -- C -- D -- E

然后解决冲突就完事了~ 

Gitflow 工作流程是一种基于 Git 的分支管理策略,广泛用于软件开发项目中,旨在为团队协作提供清晰的分支模型和流程规范。该流程围绕项目发布周期定义了分支的创建、合并、维护等标准操作,适用于中大型项目,尤其是有明确发布周期的项目[^3]。 ### 分支类型 Gitflow 工作流定义了两类主要的长期分支和若干临时分支: - **主干分支(main/master)**:用于存放生产环境的稳定版本代码。该分支只有在发布新版本时才会更新[^1]。 - **开发分支(develop)**:集成所有功能的分支,所有新功能的开发都基于此分支进行集成[^2]。 - **功能分支(feature branches)**:从 `develop` 分支创建,用于开发具体功能。完成开发并测试通过后,合并回 `develop` 分支。 - **发布分支(release branches)**:从 `develop` 分支创建,用于准备下一个发布版本。在此分支上进行版本号设置、Bug 修复等操作,最终合并到 `main` 和 `develop` 分支[^1]。 - **热修复分支(hotfix branches)**:从 `main` 分支创建,用于紧急修复线上问题。修复完成后合并回 `main` 和 `develop` 分支[^2]。 ### 流程规范 1. **功能开发阶段**:每次开发新功能时,应从 `develop` 分支创建 `feature` 分支。开发完成后,通过 Pull Request 或直接合并回 `develop` 分支,并删除 `feature` 分支。 2. **发布准备阶段**:当 `develop` 分支的功能足够发布新版本时,从 `develop` 分支创建 `release` 分支。在此分支上进行最终测试、版本号更新等工作。完成后分别合并到 `main` 和 `develop` 分支,并删除 `release` 分支[^1]。 3. **线上问题修复阶段**:当生产环境发现严重 Bug 时,从 `main` 分支创建 `hotfix` 分支进行修复。修复完成后合并回 `main` 和 `develop` 分支,并打上新的版本标签[^2]。 ### 流程图示意 ``` main: ----A-------B-----------C \ \ / develop: \-------D-----------E \ \ / feature: \-------F---G-----H release: \ / hotfix: \-------I ``` 在上述流程图中: - `A`、`B`、`C` 表示主干分支的发布版本节点。 - `D`、`E` 表示 `develop` 分支中的集成节点。 - `F`、`G`、`H` 表示某个功能分支的开发过程。 - `I` 表示热修复分支的合并结果[^3]。 ### Git 命令示例 以下是一些常见的 Git 命令示例,用于执行 Gitflow 工作流中的操作: - **创建功能分支**: ```bash git checkout -b feature/new-feature develop ``` - **完成功能分支并合并回 develop**: ```bash git checkout develop git merge --no-ff feature/new-feature git branch -d feature/new-feature ``` - **创建发布分支**: ```bash git checkout -b release/1.0.0 develop ``` - **完成发布分支并合并到 main 和 develop**: ```bash git checkout main git merge --no-ff release/1.0.0 git checkout develop git merge --no-ff release/1.0.0 git branch -d release/1.0.0 ``` - **创建热修复分支**: ```bash git checkout -b hotfix/1.0.1 main ``` - **完成热修复分支并合并回 main 和 develop**: ```bash git checkout main git merge --no-ff hotfix/1.0.1 git checkout develop git merge --no-ff hotfix/1.0.1 git branch -d hotfix/1.0.1 ``` Gitflow 工作流提供了一种结构化的方式来管理代码的版本和发布流程,适合需要明确版本控制和发布计划的项目。合理使用 Gitflow 可以提升团队协作效率,减少代码冲突,并确保生产环境的稳定性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

陈亦康

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值