GitLab 公共仓库：coding 用到的 git 命令

在公司的 gitlab 公共仓库中写代码做项目时，主要涉及以下常用 git 命令：

一、单个命令讲解

1. 拉取代码

（1）git clone [仓库 URL]‌

• 克隆远程仓库到本地（需确保 URL 正确） ‌

（‌2）git pull [远程仓库名] [分支名]‌

• 从远程仓库拉取最新代码（默认拉取 origin 仓库的 master 分支）

（3）git fetch [远程仓库名] [分支名]‌

• 仅下载远程分支更新，不自动合并

2. 分支操作

（‌1）git checkout [分支名]‌

• 切换到指定分支（如 master、develop 等）

• 加选项“-b”即创建并切换到该分支

（‌2）git switch [分支名]‌

• 切换分支（仅 Git 2.23+ 版本支持）

（‌3）git branch [新分支名]‌

• 创建并切换到新分支（如 feature-branch）

（4）git merge [分支名]

• 将指定分支的代码合并到当前分支

3. 代码管理

（1）git init

• 初始化一个新的 git 仓库

• 进入到目标文件夹，运行该命令在当前文件夹下创建一个 .git 文件夹，作为 git 的仓库

（2）git pull

• 更新本地仓库，将远程仓库的改动拉取到本地

• 运行该命令命令更新本地仓库，并将远程仓库的改动拉取到本地

（‌3）git status‌

• 查看本地仓库状态（是否需要提交、是否存在冲突等）

• 运行该命令可以查看项目下存在改动的所有文件

（4）git diff [文件名]

• 查看指定文件的详细的修改内容

（‌5）git add [文件名/目录]‌

• 将文件添加到暂存区

• 建议每次检查完某个文件单独执行 add，避免只用“add .”批量执行操作

（‌6）git commit -m "描述信息"‌

• 提交暂存区的代码（需配合 add 命令一起使用）

• “描述信息”：提炼出本次提交的关键信息即可

（7）git push -u origin [分支名]

• 将本地仓库的改动推送到远程仓库

• 建议推送到自己的分支上，避免影响公共仓库

• -u 选项：建立本地分支与远程分支的跟踪关系

（8）git log

• 查看提交历史记录

4. 冲突处理

（‌1）git rebase‌

• 将本地提交重新排列到远程分支最新提交之上（保持线性历史）

（2）git merge [远程分支]‌

• 合并远程分支到当前分支（保留合并记录）

5. 团队协作

（1）git fetch‌

• 更新本地跟踪的远程分支信息（不自动合并）

（‌2）git log --graph‌

• 查看分支合并历史（辅助团队协作排查问题）

6. 注意事项

• 确保使用公司网络环境可访问仓库

• 避免在公共分支执行 rebase 操作（可能破坏他人提交历史）

• 定期使用 git fetch 更新远程跟踪分支信息

二、常用演示示例

• “张三”在某公司的公共代码仓库中进行项目的开发，该仓库的主分支（主干）假设为“master”：

# 若是第一次开发，则需从仓库中克隆代码到本地
git clone [email protected]:gh/test.git
# [email protected]:gh/test.git 为仓库的 URL

# 仓库为公共仓库，故需要创建自己的开发分支，不可在主分支 master 进行开发
git checkout -b zhangsan
# 把自己本地的分支推送到远程仓库
git push origin zhangsan

# 查看当前仓库的所有分支(本地的)
git branch
# 切换到其他的分支，假设本地有另一个分支 zhangsan01
git checkout zhangsan01

# 若非第一次开发，即之前已经将代码克隆到本地了，需要在开发前拉取仓库的最新代码，方可进行开发(因为公共仓库存在已经有人提交过最新代码的可能性)
git pull
git pull origin master
# 以上两个命令看情况使用，判断有无跟踪关系

# 完成代码开发后，提交之前进行检查
git status
git diff [文件名]

# 检查无误后，再进行暂存(建议文件需要逐个检查，逐个暂存，不建议批量)
git add [文件名]

# 完成所有修改文件的暂存后，方可进行提交
git commit -m [zhangsan coding]

# 最后推送到远程的自己的分支
git push -u origin zhangsan
# 最后再 gitlab 上检查完后，发送 merge 请求(若无权限审批该请求，找有权限的人即可)

• 上述经历根据个人经历而言，仅供参考

三、补充 - rebase 情况

• 首先要注意使用 rebase 的场景：未共享给他人的个人分支

• 在为期较长时间的代码开发过程，每天开发前使用一遍 rebase 可让合并简单化

• 建议：在最后合并 CI 之前，再进行一遍 rebase

1. 个人分支

• 目的：保持分支 zhangsan 与主分支 master 同步，避免最终合并时冲突

# 每天开始工作前：
git checkout master
git pull origin master          # 拉取最新代码
git checkout zhangsan
git rebase master               # 将本地提交“移动”到最新 master 上

2. 整理提交历史

• 如果 zhangsan 分支上有大量琐碎提交（如“fix typo”等），可以通过交互式 rebase 整理

# 合并/编辑提交
git rebase -i master