最全的实际开发git使用讲解——版本控制——代码管理_飞道的博客

最全的实际开发git使用讲解——版本控制——代码管理

2020-05-17 14:01 314人阅读评论(0)

前言

在实际开发项目中，对于代码的控制用得最多的就是git。

git用的好，对于项目而言，是一件非常让人愉悦的事儿。

不仅仅是在代码的保存上，更是在开发上使业务逻辑和开发流程更加清晰和便于管理的不二选择。

对人团队合作开发，不可避免需要将大家的代码进行合并，那么中间就会出现很多让人头疼的问题。

如：修改，删除了别人的代码，功能不复用，高耦合，代码有问题查不到谁写的，各种甩锅等等。。。

GITLAB

GitLab是由GitLabInc.开发，使用MIT许可证的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

实际运用

在开发中，是不允许在master上进行操作的，只有最高管理权限的人才能合并master的代码，所以我们需要在master的分支上开发功能模块

同时还需要注意的是不同的模块开发是有命令规则的，并不允许随意取名！

由上图可见，develop为开发分支，所以我们所有的开发必须是在分支上完成，且是在dev分支上。

不要去找看教git的教程，直接就在master上开发，随便就合并代码，那都是不可取的，请严格遵守开发规范。

git add .
git commit -m “提交功能代码”
git push origin test_feature
提交代码三部曲，这是在代码初期最先使用到的三个命令，用来将本地的代码push到远程的项目分支上去，做为开发完成一个功能的标记。

使用 -m “ ”来记录，双引号里的内容需与提交的代码内容相关，见名知意，不可随意取名。

注意：不是任何时候都能随意的使用git commit -m这个命令，使用这个命令，必须是自己的代码功能模块已经开发完成，需要提交到远程的分支上，请求与dev分支合并的时候才能使用。

原因：是为了保证git管理项目代码的流程干净整洁，无用的commit只会让人感到厌烦，且不利于版本控制和代码阅读，同时也会涉及到代码冲突。
git commit --amend
git push -f origin test_feature
既然不能随意的使用commit -m来提交代码，那么在一个功能模块需要开发很久的时候怎么办呢，比如一个test模块需要开发一个星期，总不能等到一个星期之后再来提交代码到远程分支吧。

正好就有这样的命令来解决这个问题！

使用 -f 来覆盖远程分支上的代码

该命令表示的意思是，本次提交覆盖上一次提交的内容，也相当于更新上一个提交的代码，但是不会产生历史版本记录，这样我们始终只有一个提交，直到该模块的功能开发完成。
git pull --rebase origin dev

当我们的代码提交到分支上后，到gitlab上去请求将feature分支的代码合并到dev分支上。合并完成之后，需要将最新的dev代码拉取下来到本地。

怎么理解呢，假设现在有两个人在dev分支上开发，分别是你和你女朋友。你女朋友写代码的速度比你快，业务也比你熟悉，所以每次开发的时候提交都比你快（气不气）。

这个时候，你根据上面的步骤提交了你们代码后，现在dev上的代码就是你和你女朋友一起的代码，此时的dev分支上的代码不仅有你新增代码也有你女朋友新增的代码。

所以现在明白为啥要拉取最新的代码到本地了嘛，换句话说，无论是谁提交了代码到dev分支，且成功合并到dev分支上，咱都要拉取一道最新的代码，不然后面代码越来越多，同一个地方两个人都修改了，就会产生冲突，也不便于了解对方写了哪些功能
git merge

这个是最需要注意的命令，无论如何都不要使用命令行去合并代码。

当自己的代码，或者同事的代码需要提取合并请求到dev分支时，都不要使用git merge 合并代码，因为在命令行中是无法清晰的看到代码的变化，是否存在问题我们也不知道，一旦合并出了问题，谁合并的谁负责。

那么需要合并代码的时候怎么办呢，当然是使用GitLab，这么好的工具，如果不加以利用，咱说了半天岂不是白说了。

使用Merge Requests 提交合并请求

选择要将哪个feature分支代码合并到dev，千万不要像图片中的直接合并到master。

提交完成之后，等待项目组的其他人检查你的代码，包括但不限于查看代码的新增内容和删除内容，逻辑问题及代码优化。

检查如果存在问题，则在代码上进行评论指出问题，开发人员收到问题进行改正，改正完成后，重新推送代码（git commit --amend -->git push -f origin test_feature）到远程分支。

如果没有问题了，就将最新的代码拉取下来，开始新的开发（重新在dev上创建新的feature分支），也就是下图的过程：