这是我在软件工程课程团队大作业书写的一份我们团队需要遵照的git开发流程。

关于分支

  1. main分支为主分支和上线分支，一般成员请勿修改，完成一次迭代时将dev分支pull request到main分支
  2. dev分支是用于开发和合作的分支，请勿执行git rebase

合作流程

如何开发自己的分支(实现自己的功能或对项目进行重构等)

  1. clone仓库
  2. checkout一个自己的分支
  3. 在自己分支上进行代码修改, commit时请写清楚commit信息，以便后续版本回溯时查看信息
  4. 执行git push命令，完成后remote仓库dev分支就会出现你的<your branch>
  5. 提交pull request，将<your branch>分支内容合并到main分支

完成上面步骤后，仓库管理员可以查看request消息，决定是否将成员的修改应用到主分支

如何进行合作开发

上面的步骤是在main分支稳定的情况下，无特殊情况，一般不会出现错误，当团队进行合作开发时，如果按照上面的流程开发，那么仓库管理员的工作就会剧增，因为他需要处理团队其他成员的修改，那我们当然不希望大佬累成🐕了，我们想自己先添加别人开发的内容或查看我们共同依赖文件的修改等，如果按照上面的流程，我们的工作流程是这样的：

  1. 执行上面的1-4步骤，这样远程仓库就会出现团队成员的分支
  2. 当你需要查看其他成员的修改内容时，执行git checkout <other branch>，再执行git pull命令
  3. 切换到<your branch>，执行git merge <other branch> 命令，这时需要根据情况处理合并冲突，处理完毕之后再进行commit，此时会有默认提交消息为*merge branch of <other branch> into <your branch>*，提交完毕后，可以查看commit历史，能够发现出现其他人的历史commit消息
  4. 再进行git push操作

上面步骤可以看到，当一个团队如果只是2个人的话，只需要一个人合并然后操作就可以了，但是团队稍微多一两个人，情况就比较麻烦，比如说，A拿到B和C的内容进行合并修改，B又拿到C的，C又拿到A的，这样一是关系冗余，二是最后pull request的时候，仓库管理员还是会处理所有成员的修改，可能其他成员的修改还是不能直接放进主仓库中

利用dev分支进行开发

首先仓库管理员需要建立main分支和dev分支，对于某一个团队成员来说，他的操作流程大体是这样的：

我们认为你已经clone了仓库等，且已经在开发自己的功能，你可以按照下面的流程操作

  1. checkout到dev分支
  2. 执行git pull命令
  3. checkout到<your branch>分支
  4. 执行git merge dev命令，按照上面3步骤操作
  5. checkout到dev分支
  6. 执行*git merge <your branch>命令，此时一般不会出现冲突，git自动为我们添加merge branch …*消息
  7. 执行git push操作，此时可能出现下面的情况：
    1. push成功，此时是自上次拉取后还未有其他人推送。
    2. push失败，此时为了统一做法，我们要求处理合并冲突统一在非主分支，我们先进行版本回退，执行git reset --hard HEAD^命令，再执行git pull命令拉取到最新修改，再重复1-7步骤(有的人可能想说，那我push失败直接pull然后再处理冲突不就可以了吗，我们执行版本回退切换自己的分支进行合并，一是相当于我进行conflict解决时统一了规范，在自己的分支上解决冲突，这样可以避免有人直接在dev分支上解决冲突了之后，忘记把修改合并到自己的分支了，然后下一次修改的时候在自己的分支上还按照冲突之前的版本进行coding增加后续coding工作量，二是当有人如果有人希望查看git history的时候，我们肯定是希望减少merge branch ...这样的信息，这样虽然没有减少commit history，但是相当于是提醒我们书写详细的commit信息了(有的同学比较懒解决冲突之后直接把git生成的信息提交了))

当所有成员的功能都正常添加到dev分支后，仓库管理员将dev分支内容合并到main分支，或由你提交一个pull request

FAQ

  1. 为什么我执行了git pull，但是我看不到别人修改的内容？

    请注意你执行命令时所在的分支，同理，当你执行git push时，请不要忘记先切换到dev分支，否则remote仓库将会出现你的分支，但是正常操作的人不会查看到的你的修改

  2. 如果我觉得merge branch ...这样的消息没有意义，我应该怎么做？

    可以在*<your branch>*将git merge命令替换成git rebase命令，这样就不会出现merge消息，但是请注意，不要在dev分支执行git rebase操作，因为git rebase将会修改提交信息历史，不便于版本回溯，保留必要的合并信息是有必要的，可以方便查看是哪位成员的修改出现了问题

  3. 如果我还没有开发完成，但是我现在需要依赖其他成员的修改，我还不想要commit和push，应当怎么做？

    可以先执行git stash命令，再切换到dev分支拉取，再切换到自己的分支进行dev分支内容的合并，（可能需要处理冲突），再执行git stash apply命令，(执行这条命令时仍然有可能出现冲突，因为之前暂存的修改就有可能与合并后的内容冲突)，接下来就可以接着之前的内容继续开发了

  4. 可以给一些建议吗？

    笔者认为可以commit一次就完成一次push工作，这样可以第一时间找到冲突的问题，其他成员如果使用git rebase命令时也便于合并，如果你多次commit之后最后再push，这样用git rebase命令的成员可能需要处理很多次冲突，还可以利用vscode，github desktop图形化操作执行git命令