Git
约 1463 字大约 5 分钟
2025-01-19
1.概述
此篇用于收集 git 的常用命令,同时记录实际项目管理中可能遇到的问题
2.基本命令
git config:配置信息命令
- git config --global user.name '用户名'
- git config --global user.emial '邮箱地址'
git init:初始化仓库
git clone 仓库地址:克隆仓库
git add .: 添加代码到缓存
git commit -m "提交信息":将缓存中的代码提交到本地仓库
git remote:远程仓库管理
- git remote:列出当前仓库已配置的远程仓库
- git remote -v:列出当前仓库已配置的远程仓库,并显示url
- git remote add origin 仓库地址:配置远程仓库
git push:推送代码到远程仓库
git push【远程主机名】【 本地分支名】:【远程分支名】(如果本地分支名与远程分支名相同,则可以省略冒号),其中 远程主机名一般为 origin
# 将本地的 master 分支推送到 origin 主机的 master 分支 git push origin master # 将本地的 master 分支推送到 origin 主机的 main 分支 git push origin master:main
例子:git push -f origin master,强制推送
git pull:从远程获取代码并合并本地的版本
git pull 【远程仓库名】 【远程分支名】:【本地分支名】
例子:git pull origin master:main,将远程主机 origin 的 master 分支拉取过来,与本地的 main 分支合并
3.分支管理
3.1 分支命令
创建分支:git checkout
- 创建新分支并切换该分支:git checkout -b 分支名
- 切换分支命令:git checkout 分支名
查看分支:git branch
- 查看本地分支:git branch
- 查看远程分支:git branch -r
- 查看本地和远程分支:git branch -a
合并分支:git merge
将指定分支合并到当前分支:git merge 【其他分支名】
切换 main 分支并合并 feat-message 分支
git checkout main git merge feat-message
解决合并冲突:当合并过程中出现冲突时,Git 会标记冲突文件,你需要手动解决冲突。打开冲突文件,按照标记解决冲突,解决完,使用 git add 冲突文件、git commit 提交合并结果
删除分支:
- 删除本地分支:git branch -d 分支名
- 删除远程分支:git push origin -d 分支名
3.2 git merge 和 git rebase 的区别
git merge
:把两个分支的历史保留下来,然后创建一个新的“合并提交”来把它们连接在一起。这样做不会改历史,比较安全,也适合多人协作。就像两条河流汇合在一起,会留下“汇合点”的痕迹。git rebase
的做法是:把你当前分支的提交“剪下来”,然后一个个地重新应用到目标分支的末尾,让整个历史看起来就像你一直在那条主线上开发一样。不会有“分叉”和“合并”的痕迹,历史更线性。就像你把旁边那条支流里的水重新倒进主河道,不留分支的痕迹。
举例:
如下图,有两个分支:develop、feature
第一,使用 merge 命令将 develop 分支合并到 feature 分支,如图,创建了一个新的“合并提交”F,同时保留了两个分支的提交记录,适合于在团队协作中合并不同的分支,适合保留开发的轨迹。
第二,使用 rebase 命令将 develop 分支合并到 feature 分支,如图,修改了两个分支的跳记录,同时没有额外的合并提交,将当前分支的提交”重新应用”到合并分支的最前面,更线性,适合在个人分支开发时使用,以保持提交历史的干净和线性
3.3 git pull 和 git fetch 的区别
- git pull 和 git fetch 都是用于更新代码
- git fetch:从远程仓库获取所有的更新,并下载到本地仓库的远程跟踪分支中,不会修改本地分支,需要手动合并本地代码
- git pull: 是
git fetch
和git merge
的结合。它会先执行git fetch
来下载远程仓库的更新,然后自动尝试将这些更新合并到当前的本地分支
3.4 分支策略
分支策略,其实就是团队在开发过程中如何管理和使用 Git 分支的一套规则。
Git Flow,为不同阶段的工作分不同的分支,比如:
main
: 是线上发布用的稳定分支develop
: 是日常开发分支,所有功能分支从这里拉feature/*
: 用于开发新功能release/*
: 用于准备版本上线前的最后整理hotfix/*
: 用于紧急修复线上 bug
项目实际开发的 Git 流程:
- 所有人从
main
拉分支(比如feature/xxx
) - 每个分支对应一个功能或修复
- 开发完成后提交 Pull Request(合并请求)
- 通过代码审核和自动测试后合并回
main
- 合并后可以立即上线
- 所有人从
4.提交代码信息规范
Git 提交代码时,需遵守的提交信息规范:
- init:初始化项目。
- feat:新功能(feature),用于提交新功能。例如:feat: 增加用户注册功能
- fix:修复 bug,用于提交 bug 修复。例如:fix: 修复登录页面崩溃的问题
- docs:文档变更,用于提交仅文档相关的修改。例如:docs: 更新 README 文件
- style:代码风格变动(不影响代码逻辑),用于提交仅格式化、标点符号、空白等不影响代码运行的变更
- refactor:代码重构(既不是新增功能也不是修复 bug 的代码更改),用于提交代码重构。例如:refactor: 重构用户验证逻辑