git clone 一部分_git 的版本控制--在项目中的实战控制

在项目中，工程的开发不止一个人，也不止一个工程，在项目中常常会出现因为版本的控制，导致上线不成功，代码丢失冲突等问题，所以版本控制是一个项目中很头疼的问题，也是很容易出错的问题。这里先介绍一下经验。

下面的从这几个点说起：项目创建，远程仓库的创建，创建分支、拉代码，提交代码，回滚，请求合并，解决冲突，版本合并，最后上线版本控制

注：这里远程仓库我是拿码云做的例子的！！！！

首先创建一下工程项目，在远程库里创建项目

这里是创建好远程库

这里只有一个分支master分支，当然在项目中不能直接在master分支中开发，比如说这个项目中有5个人开发，所以也可以针对每个人创建一个分支， 如 dev-ztt, dev-zlp, dev-dw, dev-wp, dev-zyh, 这里注意命名，dev表示开发环境，ztt 表示是谁在开发（赵天天）。

这里，创建远程分支，是从master分支克隆出来的。

这里是新创建的分支。

作为管理员肯定有一套基本的代码框架。所以先把基本代码框架传到远程git库，这里当然是master分支。

首先将远程的git库克隆到本地，这里管理可以有操作做的权限。

git clone -b master https://gitee.com/dayday1996/projectTest.git   

这里将远程的库clone 下来了 ， 看下面有 .git 的隐藏文件夹， 就说明成功clone下来了，这次项目的相关记录都在 .git 文件里面

然后将基本的版本复制到里面

执行

git add .

git commit -m 'feat: 新增的基本版本库'

git push

这里就可以看到在master 分支

这里就可以看到 新提交的文件了

这里作为管理员基本的项目框架就算完成了

下面作为其他分支的开发者可以进行开发了，

首先创建本地库，将远程代码克隆下来

git clone -b dev-ztt https://gitee.com/dayday1996/projectTest.git

这里发现并没有 刚才新增的 文件， 在这个过程中，因为先做了创建分支，后给master 同步的代码，所以现在的分支没有新传上去的代码；如果说先给master 传代码，后创建分支，那么就会有代码，所以基于这种情况所以 在dev-ztt 这个分支上需要将远程的代码拉下来

git pull origin master

看看现在dev-ztt分支就有了 基本代码了。

现在说一下在自己的分支开发的常规操作

在自己的分支开发，提交，等一系列的操作，都是随意的，说白了就不会干扰到他人，也不会受到他人的干扰，比如说，防止电脑代码丢失，每天一提交代码；或者是完成一个功能，提交一次代码等，都是随意的。

先从代码提交开始吧，

git status

这里主要看见这次修改了那些文件， 在这里可以新增了一个文件，

git add .

git add . 说明我要准备提交所有文件， 但是这里不提倡 git add . , 这里比较提倡修改了那个文件， 就提交那个文件。 为什么呢？ 比如这次修改了好多文件， 但是有那么几个文件自己改了，但是不想这次提交，或者是那几个文件，是别人写的代码，这样会造成冲突，或者把代码搞错了，所以提倡 git add addfile.txt ， 这样既可以看清提了那个文件，也不容易出现问题。

git commit -m 'feat: 新增了一个文件'

这里的意思是， 刚刚选中的文件马上要提交了，但是我得注释一下，这次提交主要是用来干啥的，解释说明，留下痕迹；

注： feat :表示新增， fix：表示修改， 这个只是自己这么定义的一个规范，方便好看出来这次意图。

最后一步了，git push , 正常操作是git push origin dev-ztt, 这里本来是在dev-ztt分支，所以可以这么简写。

这里就可以在远程库中看到新增的文件了。可是如果突然间发现这次版本更新的不太对，想撤回怎么办？

这里首先查看日志： git log

然后 找到你要回滚的版本号

git reset --hard 0d67e8a44ef103c24c8a007b29cf483b1ec02c32

这里就可以看出回退到那个版本了

然后执行 git push -f

这里远程分支就看不到了新增的文件了， 这里只是针对自己分支文件提交以及撤回的操作做了简单的说明。

在前面说过在自己的分支上可以随意操作没什么事，但是在团队中，你的代码迟早要合并master的，所以，在合并的过程中，很可能会遇到冲突。那么什么是冲突呢？冲突就是同一个文件的同一个代码被多个人改变了，那么系统就懵逼了，那我到底要以谁的代码为主呢。所以那谁先合并，就按照谁的为主，后合并的如果修改的是同一行代码，那后面的就是冲突。举个例子在多人合作中，配置文件可能会被多人修改，这里会经常有冲突。那么怎么解决冲突呢，首先在提交的时候会报冲突，然后这里将最新的代码（master）拉下来。

git pull origin master

这里就是将最新的代码拉下来，包括和你有冲突的代码，这里我平时用vscode编辑器，会明确告诉你那一部分冲突，然后有三个选项，保留当前代码， 保留拉下来最新的，两者都保留。那么问题来了，你怎么知道要留那一块代码呢，这里就考虑你人际关系的时候到了，你去找到和你代码有冲突的人，和他协商留那一块，这个解决完成之后，就重复之前的操作，将新改的文件给提交上去

git add 你改的文件

git commit -m 'fix: 解决了什么冲突'

git push

然后将你的代码合并到master 主分支上面

这里首先dev-ztt 有一个请求的过程，这里有个管理员，专门对你的代码会进行审查，如果不符合要求，或者有冲突，管理员直接可以打回，一下是合并的整个过程。

这里由创建项目、分支、拉代码、提交代码、版本回滚、解决冲突、版本合并已经说完了。后面说一下上线版本的控制，这里遇到好多坑，被客户已经吐槽的不行了。

方法一：

这里创建一个专门用于上线的product 分支，这个分支主要用于上线版本控制，这个分支不用于写代码的，是专门从master 分支拉代码的，管理员说大家准备一下代码，说要准备上线了，把代码往master 上面合并一下， 然后master就有了新的产出物。用master的代码测试好了没啥问题后，就把这次的作为一个基版拉到product分支上，并且在这次拉的过程中注释好他们的版本号，然后通过product 分支出上线的版本。

那么可能会有好多人有疑问，master 是新的产出物，那为啥不用master 出上线版本呢？其实这个很简单，因为master是主分支，大家的开发的代码不断的在master分支上面提交，有的可能开发到一半就提上来了，这样会导致master不可控，另一个原因是，比如这次上线的版本有问题，需要撤回到上一个版本来，如果在master分支，那么很难找，还很乱，而且可能会影响到新开发的代码的版本。

方法二：

通过打标签，就是说这次要上线了，然后给这次稳定的代码打标签，然后上线版本从这次标签里出。

git tag -a v1.0.1 -m"这次要上线了"

git push origin v1.0.1

这样远程也有了标签，，然后从这里出版本

---

20191222 20:33 赵天天