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

前言

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

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

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

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

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

GITLAB

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

实际运用

一、dev分支开发功能模块

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

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

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

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

二、首次提交代码到远程

1. git add .

2. git commit -m “提交功能代码”

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

   使用 -m “ ”来记录，双引号里的内容需与提交的代码内容相关，见名知意，不可随意取名。
   
   注意：不是任何时候都能随意的使用git commit -m这个命令，使用这个命令，必须是自己的代码功能模块已经开发完成，需要提交到远程的分支上，请求与dev分支合并的时候才能使用。

   原因：是为了保证git管理项目代码的流程干净整洁，无用的commit只会让人感到厌烦，且不利于版本控制和代码阅读，同时也会涉及到代码冲突。

三、追加需改命令使用

1. git commit --amend

2. git push -f origin test_feature
   既然不能随意的使用commit -m来提交代码，那么在一个功能模块需要开发很久的时候怎么办呢，比如一个test模块需要开发一个星期，总不能等到一个星期之后再来提交代码到远程分支吧。

   正好就有这样的命令来解决这个问题！
   
   使用 -f 来覆盖远程分支上的代码

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

四、本地分支与远程dev分支合并代码

• git pull --rebase origin dev（推荐使用）

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

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

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

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

五、千万别用merge合并代码

• git merge（千万不要用）

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

  当自己的代码，或者同事的代码需要提取合并请求到dev分支时，都不要使用git merge 合并代码，因为在命令行中是无法 清晰的看到代码的变化，是否存在问题我们也不知道，一旦合并出了问题，谁合并的谁负责。
  
  那么需要合并代码的时候怎么办呢，当然是使用GitLab，这么好的工具，如果不加以利用，咱说了半天岂不是白说了。
  
  使用Merge Requests 提交合并请求

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

  提交完成之后，等待项目组的其他人检查你的代码，包括但不限于查看代码的新增内容和删除内容，逻辑问题及代码优化。
  
  检查如果存在问题，则在代码上进行评论指出问题，开发人员收到问题进行改正，改正完成后，重新推送代码（git commit --amend -->git push -f origin test_feature）到远程分支。

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

  

以上就是一套完成的gitlab管理代码和开发的流程，但是需要提请各位的事，这只是最基础的流程，我们由上图可以知道分支不只dev和feature两条分支，具体问题需要大家在实践中去解决，但是万变不离其宗，说白了就是要在推送代码和拉取代码的过程中，尽量做到规范和仔细。

六、解决冲突

问题描述

• 在代码合并的过程中，极大可能会遇到冲突的问题。
  （还记得上面提到的合并时的注意点嘛）
  

原因分析

• 功能在开发的时候，会在分支上进行多次git commit --amend，就会存在多少历史提交记录，假设提交三次到远程分支，那么在从dev分支上拉去最新代码到本地合并时就会极大可能存在冲突

解决冲突

1. 首先拉去最新的代码到自己的开发分支
   git pull --rebase origin dev
2. 检查代码冲突的地方，代码是谁写的，就让谁去删除冲突的代码，不要随意动别人的代码。
3. 代码冲突删除完成后，需要使用命令
   git add .
   git rebase --continue
4. 这是将进入第二次commit 的代码历史中，继续解决冲突，直到最后一次commit。
5. 解决完全部冲突后，再提交代码到自己的远程开发分支保存代码。
   git add .
   git commit --amend
   git push -f origin xxxx_feature

七、删除远程已经合并的分支

• git remote prune origin

• 删除本地分支：git branch -d 分支名

• 强制删本地：git branch -D 分支名

• 删除远程分支：git push origin --delete 分支名

问题描述

• 项目进行了一段时间后，回创建大量的分支，有些分支是已经合并，不需要在继续开发的分支，如果不及时删除，日积月累就会存在很多，影响git branch -a 查看分支的使用
  

解决办法

• git remote show origin
  查看历史分支状态
  

• git remote prune origin
  删除已经合并的历史分支
  

八、合并已经push到远程分支的多个commit

问题描述

在开发过程中，可能因为疏忽导致提交了多次commit，不仅会造成版本控制混乱，更会影响到合并时的代码走读，既不美观也不方便。

今天我就遇到了这个问题，同一个功能分支提交了两次commit

解决办法

git rebase -i HEAD~2
表示将最近的两次提交进行合并

注意：进入到合并状态之后

（我的代码因为已经合并了，所以看不到代码版本，用的网上的图，但是基本一致）
pick代表选择这个commit，squash代表合并这个commit
将需要合并的版本进行合并，如：squash 6470ccc
合并完成之后

原本两个commit，就合并完成为一个commit。

九、忽略不需要提交的文件

问题描述

大多时候，开发人员是在自己本地进行开发合测试，当程序没有问题后再推到线上进行合并，但是不想将本地测试的文件或者日志提交怎么办呢

以上提交存在大量的日志文件，这对于项目来说没有用。我们就不希望将它提交到线上分支。

解决办法

git rm --cached 用于已经将不想上传的文件推到了线上分支，删除的也是线上的文件，本地文件会继续保留下来。

关注收藏不迷路，持续更新