怎么取名都不队-代码版本管理

怎么取名都不队-代码版本管理

项目	内容
这个作业属于哪个课程	北航敏捷软件工程
这个作业的要求在哪里	团队项目-代码管理准备

一、团队代码

本次作业我们使用GitCode平台来完成，由@鲁文澔 担任DevOps的管理员。

1、仓库地址

• https://gitcode.net/buaa-se-2023-dkhtn/buaase2023-teamversioncontrol

2、完成 Task. HotFix! 后新建的代码仓库地址

• https://gitcode.net/LGJ1617026914/buaase2023-teamversioncontrol

3、需要说明的状况

• 代码管理要求使用Github或者GitCode完成，考虑网络因素，我们在GitCode上完成
• 代码管理平台我们选用Gitlab实现，DevOps等在Gitlab的仓库部署，本仓库仅用于本次作业
• 同学E 因为个人账户无法登录GitCode(悲)，使用团队账户操作

二、两次迭代总结

2.1 第一次迭代

第一次迭代后同学B 的修改丢失了

原因是推送但是忘记发MR了，而且忘记自己忘记发MR了，以为是没有在发起MR时设置合入后删除原分支，便手动删除了远程分支，造成了改动丢失。

完成一次迭代的过程

迭代前(开始Coding前)

1. 更新需要基于其签出新分支的代码
2. 基于该分支按照命名规范签出新分支

迭代中(开发指发起MR前)

1. 开发自己的代码
2. 少量多次及时commit
3. 在发起MR前对目标分支进行rebase

迭代后(发起MR之后)

1. 需要有除了MR发起人之外的至少1名成员Approve后才可以合入
2. 在正式项目中，需要自动化测试通过后才允许合入
3. 合入以squash形式合入，避免主分支commit过多，Merge Request的title为所有commit的摘要

2.2 第二次迭代

分支图

• 根据分支图看，在Task1中有部分同学是从main分支签出的新分支，这不好，应该从dev分支签出
• 不建议在团队开发中使用Fork – PR的模式，这样难以跟随其它的改动
• 建议每次签出新功能分支时都会到dev进行签出

三、本次心得记录

1、遇到的问题及如何解决与避免

同学A

提交分支合并请求并通过后，该分支在仓库中被移除，此时直接pull会出现分支不存在的问题。

解决办法为本地checkout到dev分支，本地dev分支对应GitCode中dev分支存在，即可正常拉取。

同学B

在Task1中，push到远程仓库后忘记发起了MR，导致了frontend.json的丢失

应该规避掉不不规范操作，例如直接删除分支，同时设置部分分支MR模板，合并后删除分支

避免不合规操作导致修改丢失

同学C

在提交feature/TA-2的pr时，由于这个分支已经落后于dev分支，所以要进行rebase。我先进行了git rebase dev操作，然后需要逐个解决冲突，按照作业要求将其改成了列表形式，每改一个冲突都要git add file & git rebase --continue一下，直到所有冲突解决。

由于一开始我不了解git rebase等git操作以及如何解决冲突，所以是在git bash上操作，后来用vscode解决了冲突，但是由于对vscode中git操作还是不甚了解，所以之后还要继续摸索。

同学D

在修改分支feature/anime-2并提交pr后，由于该分支落后dev分支45个commits，且存在冲突因此需要先解决冲突后才能合并入dev。因此我在GitCode处直接对其按照要求进行修改，解决冲突最后能合入dev分支。

😢另外，在GitCode直接解决冲突使用的方法貌似是git merge而非git merge --rebase，因此过去的git commit变得极其不清晰，我认为在后续的团队作业应该避免这一点。

🤞通过在本地使用rebase解决冲突，使得他人的commit变得清晰可见，甚至可以考虑在pr时将多个commit squash👏，使得dev,main等分支commit info处于pr的粒度而非个人的commit上。

同学E

1. 分支命名没有参照项目要求的格式，没有type。解决：使用git branch -m new_branch_name命令重命名分支，push时需要使用git branch --set-upstream-to origin/new_branch_name命令
2. 从错误的分支签出，Task1直接从main分支签出，而不是dev。解决：删除分支，从正确的分支签出。
3. 新建PR时应考虑选择扁平化分支，这样可以使main，dev分支上的commit记录更加简洁。

同学F

1. 关于pull-request的使用，最初是通过fork的方式发出合并请求，但是发现这种方式是“一次性”的，多个任务下会比较麻烦，因此后续改成了clone原仓库，push到个人分支再发出merge request的方式
2. 分支命名不规范（幸好没有push），在本地删除重新创建分支
3. commit信息不规范，使用git commit --amend的命令进行修改

同学G

1. 分支起名不符合规范，解决方法：删除PR和自己的分支后重新操作，或者重命名分支，但是这又导致本地分支不能跟踪远程分支，需要git branch -u重新设置。
2. 本地分支没有对应的远程分支了，比如已经合并的分支，需要prune。
3. commit信息不规范，想要修改但是没有找到方法，好像需要rebase，不敢操作。
4. commit错了地方（不属于任何分支的HEAD上）且找不到了，解决方法：reflog 找到对应commit的SHA。

2、软件操作理解

（1）git merge

• merge操作会在当前分支中将更改集成，并创建一个新的commit，此次的commit会连接两个分支的提交历史，如下图。合并操作不会破坏dev_merge分支原有的commit记录，可以随时回退到merge之前的版本。但是，每次merge操作会将上游分支master分支上的所有更改的commit记录增加到dev_merge分支上，会对dev_merge分支上的提交历史产生污染。

（2）git rebase

• rebase操作是把功能分支上的起始commit记录放到master分支的最后一次提交上，然后依次合并重写功能分支的commit message，如下图。rebase操作会舍弃 master 分支上提取的 commit，不会像 merge 一样生成一个合并commit。