基带处理器项目Git使用

项目代码仓库概览

问题速查：7.4 我遇到的问题及解决方法

重要注意事项

1. 在开发功能之前必须先拉取最新分支。

git pull origin main

2. 只能在自己命名的分支进行开发，禁止在main分支开发。

# 确认当前分支：
git branch 
# 或者查看log
git log

3. 提交分支只能提交自己命名的分支。

# 推送当前分支到远程仓库的`ppeng`分支：
git push origin ppeng

4. 提交分支之后应该告诉root用户审计并合并工作。
5. 项目开发禁止使用notepad++

1.1 仓库地址与克隆方式

• 仓库地址就是项目的“家门”，有两种常见格式：
  • HTTPS 地址（本项目暂时用不到HTTPS访问）
    适合第一次用 Git 的新手，输入用户名和密码就能进去。
  • SSH 地址："user_name"@10.147.19.26:/repo/BandPJ
    适合常用 Git 的人，配置一次 SSH 密钥后，再也不用输密码。
• 克隆就是把项目复制到你电脑上：

# 打开本地终端，输入：  
git clone 'user_name'@10.147.19.26:/repo/BandPJ

eg：ppeng的仓库地址：git clone [email protected]:/repo/BandPJ
回车后，项目文件夹就会出现在你电脑里。

1.2 核心分支作用

我们把代码比作一本书，分支就是不同的“草稿”：

• main：项目的正式分支，只能拉取在此基础上开发，不能随便改。
• "user_name_dev"：你个人的“草稿本”，新功能先写在这里。稍后再合并(merge)到主分支，再提交。
  • eg：ppeng的个人分支：ppeng_dev，分支新建及管理相关的命令请自己查询。
    平时开发时，你在自己的“草稿本”上写代码，最后草稿本整理成新书（main）。

1.3 保护规则一览

保护规则就像“家长管孩子”，防止乱动重要东西：

• 远程的main 分支默认被保护，不能直接推送，本项目只能推送到自己的开发分支。
• 推送自己分支后需要root用户合并分支，就像作业写完要整理提交放在作业堆。
• 如果检查不通过，可以评论“回去重写”，你改完再提交一次即可。
  这些规则需要各位约定好，新手只需记住：

“别直接在 main 分支上改代码，先创建自己的user_name分支再动手。”

开发环境准备

2.1 安装 Git 与配置身份

略，见Keeps-up

2.2 生成 SSH 密钥并绑定

略

2.3 首次克隆项目代码

• 复制仓库地址（HTTPS 或 SSH 都行，本项目选 SSH）。
• 在 Git Bash 里执行：
  git clone [email protected]:/repo/BandPJ
  没有报错就表示下载完成。
  进入新生成的文件夹，用 ls能看到项目文件，说明家里的大门已经打开，可以开始干活了！

日常开发工作流

3.1 创建个人 feature 分支

• 先把“主分支”拉到最新：

git pull origin main

• 再新建自己的“便签条”：

git checkout -b 'your_name'
git branch
# 类似输出  
* ppeng

成功后你会看到命令行前面括号里变成刚起的分支名，就可以放心写代码了。

3.2 提交并推送代码

• 写完一小步就存档：

git add *                        ← 把改动放进“背包”
git commit -m "添加相关的修改说明"  ← 给背包贴标签

• 第一次推送到远端：
  git push -u origin 你的分支名
  以后同一分支再推，只用 git push 即可。
  看到“Create a merge request”提示，就是仓库在喊你：“可以交作业啦！”

3.3 发起合并请求（选看

• 打开仓库网页，会弹出“Create Merge Request”按钮，点进去。
• 填 3 个空：
  1. 标题：写清做什么，如“添加登录按钮”
  2. 描述：复制粘贴 commit 信息即可，新手无需长篇大论
  3. 目标分支：选 use_name（千万别选 main）
• 点“Submit”后， 告知root用户。
• 等审核通过“Accept”后，你的代码就合并成功，任务完成！

分支与合并策略

4.1 常用分支类型

• main：正式版，像“已出版的书”，不能随便改。
• dev：开发版，像“草稿本”，新功能先写这里。（本项目暂不用）
• user_name：个人“便签”，写自己的小功能，写完贴到草稿本。

4.2 合并方式选择（选看

• Merge：把便签直接贴到草稿本，历史完整，适合保留过程。
• Squash：把便签压成一张“总贴纸”，历史干净，适合小功能。
• Rebase：把便签撕下来重贴，历史一条线，适合追求整洁。

提交规范与注释模板（重要）

5.1 提交信息格式

一句话模板：<用户>: 做了什么

eg：ppeng: 添加了xx文档 、lucky：修改了xx部分逻辑

• 注意：总共不超过 50 字，句尾不要加句号。

代码冲突预防与解决

6.1 预防：及时拉取远程变更

每天开工先跑：

git checkout main
git pull --rebase origin main

• 如果当前分支有未提交的更改，rebase 可能会失败
  把别人的最新代码拿下来，再在自己的分支上继续写，冲突概率直线下降。

6.2 解决：使用 IDE 合并工具（重要）

本部分是解决冲突的重要内容，有什么不懂地方直接问AI，并选择性采用AI的建议。
尽量改本地的文件，不要强行进行危险操作。

1. 当 git pull 或 git merge 提示 CONFLICT 时，别慌。
2. 用 VS Code 打开冲突文件，会看到“<<<<<<<” 分隔线。
3. 点击“采用当前更改 | 采用传入更改 | 保留双方”，保存即可。
4. 解决完再次 git add . → git commit → git push。

6.3 回退：撤销错误合并（重要）

本部分关于撤销误操作，在此只做简单介绍，建议直接问AI。
如果不小心把错的代码合进 main，可以：
git revert <合并的main分支commit号>
系统会生成一次“反操作”的新提交，原代码不会被删掉，只是“抵消”改动，最安全。

附录

7.1 常用命令速查

git clone <地址>               # 第一次把项目搬下来
git checkout -b feature/xxx   # 新建并切换分支
git add .                     # 把改动放进暂存区
git commit -m "feat: 描述"     # 提交
git push -u origin 分支名      # 第一次推送
git pull --rebase origin dev  # 保持最新
git log --oneline -10         # 看最近10次提交
git revert <commit>           # 安全回滚

7.2 常见问题 FAQ

Q1 误删了分支能找回吗？
A：执行 git reflog 找到最后一次提交的哈希，再 git checkout -b 分支名 <哈希> 即可。
Q2: 我在 git status 里看到warning: in the working copy of 'vp_src/logic_unit.sv', LF will be replaced by CRLF the next time Git touches it 这是什么意思？要不要处理？
A:

1. 是什么含义
   该文件当前以 Unix 风格 LF（\n）做行尾，但 Git 检测到你在 Windows 且 core.autocrlf=true，于是提示“下次 add/checkout 时会自动转成 Windows 风格的 CRLF（\r\n）”。
2. 有什么影响
   仅提示，不会损坏代码；若仓库跨平台（Linux CI、Mac 同事等）可能产生“整行 diff”噪音。
3. 禁用自动替换LF为CRLF（可选）
   git config --global core.autocrlf false # 全局配置

7.3 内部支持渠道

• 建议新建微信群，用于项目交流

7.4 我遇到的问题及解决方法

• 12/6/25
  • Q：我在提交时写错了提交信息，怎么修改
    A：使用git commit --amend然后使用编辑器修改，此操作只会改变提交信息