• Git教程Git多人协作开发


    Git可以完成两件事情:

    1. 版本控制

    2.多人协作开发

    如今的项目,规模越来越大,功能越来越多,需要有一个团队进行开发。

    如果有多个开发人员共同开发一个项目,如何进行协作的呢。

    Git提供了一个非常好的解决方案 ---- 多人协作开发。

    1.多人协作原理

    典型的做法是,首先创建一个git服务器,被多个人所操作。

    1.多人协助实现

    分为如下几个步骤:

    1.创建一个git裸服务器 (git init --bare)

    2.从裸服务器将版本库克隆至本地(git clone )

    3.本地常规操作

    4.推送版本至服务器 (git remote +  git push origin master)

    5.从远程服务器拉取版本(git pull)

    一般而言,我们需要在Linux服务器上来搭建我们的git版本服务器,每个公司都会有。

    由项目负责人开始。

    我们现在是windows系统上模拟这个操作过程。

    (1).创建一个git裸服务器 (git init --bare)

    由负责人来完成的。服务器新建一个项目目录,如git-server

     

    创建完毕,我们发现git-server内容和上次的不太一样。

    上次使用git init 创建之后,会有一个隐藏的.git目录。目录中的才是现在看到的内容。

    也就是说,现在根本就没有.git目录了。

    这就意味着在这个目录中,不能做常规的开发。

    (2).从裸服务器将版本库克隆至本地(git clone )

    在git版本服务器,一般是不做任何开发工作的。如果要开发项目,就需要将版本库从服务器克隆到本地。

    假设有一个程序员甲,开始自己的工作了。

    使用命令 git clone git版本服务器地址

    在windows下面,就是使用绝对路径,如下:

    然后,甲就可以在这个目录下,进行常规开发。

    我们可以在这个目录下,创建自己的工作区目录,完成常规开发。

    (3).本地常规操作

    甲可以,在本地进行常规开发。

    这个过程,可以反复进行。

    我的第一个模块(功能)开发完毕。需要将其推送到服务器。

    (4).推送版本至服务器 (git remote +  git push origin master)

    当在本地完成一个模块(功能),需要推送到服务器,供其他同事使用。

    第一件事情,需要知道服务器在哪儿?

    git remote

    第二件事情,直接推送即可

    git push origin master

    其中origin就是使用git remote得到的远程服务器的名称。

    master表示是主分支。

    对于甲来说,它的工作已经告一段落了,该轮到乙程序员出场了。

    乙程序员,首先将版本库从git服务器上克隆到本地。

     

    打开这个目录,然后进可以看到最新新的内容,如下:

    对于乙而言,可以在本地进行常规开发。与此同时,甲继续他的常规开发。

    模拟乙程序员在本地的开发。

    将完成的工作,推送到git服务器。

    回头,再看看甲的开发。

    甲收工,准备下班了。在下班之前,需要将最新版本推送到git服务器。

    开始使用命令,执行如下:

    结果出错了,why?

    之所以会出错,原因在于:其他程序员已经将最新的一个版本提交到git服务器上,但是你在提交之前,已经不是最新的。

    在这种情况下,甲,需要先从服务器拉取最新的版本。

    (5).从远程服务器拉取版本(git pull)

    在多人协助开发时,每个开发人员在推送自己的最新版本时,都需要确保当前版本是最新的,所以就需要先获取最新版本,也就是说需要从服务器拉取最新版本到本地。

    需要使用 git pull命令

    如此一来,甲当前就是最新的版本。

    然后再次使用 git push 命令推送至服务器。

    接下来需要分两种情况:

    如果有新的开发人员加入进来,重复2~5过程。

    如果不是新的开发人员,重复3~5过程。

    比如,对于乙而言,其实它现在已经不是最新的版本了,所以需要使用 git pull 拉取最新版本。

    所以,对很多开发人员而言,一打开电脑,马上先git pull,拉取最新的。然后进行常规开发,

    开发完毕之后,在git push之前,还需要使用git pull再拉取一遍。

    如果还有一个新的程序员丙,加入了,怎么办呢?

    需要先git clone

    然后就进行常规开发,推送版本、拉取版本。

    在整个协作开发时,有时候会出现冲突。通常都是由于开发人员分工不明确导致的,所以如果出现这种情况,需要两个程序员协商解决。

    3.分支

    (1).什么是分支

    在前面所有的操作当中,我们一直使用的是master主分支。以刚才的项目版本控制为例

    有四个版本,在我们的版本库中,都是存在于master主分支上的。

    图示如下:

    如果我们的项目本身比较简单,只需要有主分支master就够了。

    但是,实际上并不是这样的。

    在这个世界上,有一种软件叫做开源软件 -- 源代码开发,所有的人都可以免费使用。

    开源软件是由世界上无数的程序员共同来开发。

    每个程序员都可以创建一个自己的分支,这个自己分支和主master完全独立的两个分支。

    相应的,每个程序员都可以拥有自己的分支,可以进行任何的开发,此时和master没有什么关系的。

    一旦开发完毕,就可以将你的分支合并到主分支上去。

    什么时候会用到分支呢?

    假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险,怎么办?

    你可以创建一个属于自己的分支,别人看不见,还继续在原来的分支上工作,而你在自己的分支上进行开发,等开发完毕,合并即可。

    在开源世界中,需用大量的程序员共同维护一个项目。也是需要使用分支,如Jquery。

    (2).分支的基本操作

    基本操作有如下几个:

    1. 查看当前分支 (git branch)

    2. 创建分支 (git branch 分支名)

    3.切换分支(git checkout 分支名)

    4.分支上的常规操作

    5.分支的合并 (git checkout master + git merge 分支名)

    6.分支的删除(git branch -d 分支名)

    查看当前分支 (git branch)

     

    其中的 * 表示 当前分支。

    默认情况下,只有一个master主分支。

    创建分支 (git branch 分支名)

    切换分支(git checkout 分支名)

    创建完成之后,就有了一个新的分支,但是并没有立即切换到新的分支,需要使用命令切换一下。

    分支上的常规操作

    已经切换到b1分支上,就可以在b1分支进行常规开发和操作。

     

    使用git add 和git commit提交。

    使用git log查看即可:

    与之对应的,我们再次切换到master分支上看看是什么情况:

    说明在master分支上,并没有新提交的内容。

    分支的合并 (git checkout master + git merge 分支名)

    分支的合并,一定是在 主分支上进行的。

    只能在主分支合并其它分支。

    需要两步:

    1) 切换到主分支

    2) 使用git merge 分支名 进行合并

    再次查看master的一个log情况,如下:

    分支的删除(git branch -d 分支名)

    使用命令git branch -d 分支名

    如果你发现你的分支中所做的开发没有任何用处,也可以不合并直接删除。

    (3).分支的原理

    分支的过程及原理如下:

    默认只有master的情况下,master总是指向最新的版本,而HEAD指针总是指向master的。

    现在,我创建了一个新的分支dev,将当前分支指定为dev,此时,master和dev都指向当前最新版本,但是HEAD指针已经指向了dev分支。

    接下来,我们提交了新的版本,dev指向最新版本,而master则原地不动。

    HEAD指向当前分支dev的。

    当在dev分支上完成开发之后,可以将它合并到主分支master上。

    合并时,需要先切换到master,意味着HEAD指向了master,合并的时候其实就是将master和dev的最新版本同步。

    dev分支的使命已经完成,没有什么作用了,将其删除掉。只剩下一个主分支。

    转:http://www.cnblogs.com/Josiah-Lin/p/6847973.html

  • 相关阅读:
    Atitit orm 之道 艾龙著 1. 一、ORM的由来 1 2. ORM的组成:      2 3.  常见的ORM框架:      3 4. 、ORM与数据持久化的关系 3 5. Atitit
    Atitit 移动互联网 产业维度 1. 移动互联网带来的模式变革  1 2. 从视窗到“苹果与机器人”,软件发展模式的颠覆  2 3. 第3章 从X86到ARM,蚂蚁绊倒了大象  2 4. 第5
    Atitit 装备工具分类 attilax总结 艾龙著 工具链体系 武器与软件行业工具也是很近似的的。 1. 分类思维 1 1.1. 总分类:冷、热 1 1.2. 轻、重、大规模杀伤性 1
    Atitit 区块链之道 attilax著 艾龙著 1. 金融=制度+技术+信息 1 2. 第一章可信的协议 1 3. 第二章引导未来:区块链经济七大设计原则 1 4. 第五章 新商业
    Atitit 几大研发体系对比 StageGate体系 PACE与IPD体系 敏捷开发体系 CMMI体系 艾龙 著 1. 3. 1.5:业界领先的研发管理体系简介 2 1 2. 《产品及生命周期
    Atitit 传感器之道 1. 视觉传感器 摄像头 1 1.1. 一、光线传感器: 1 1.2. 二、距离传感器: 1 1.3.    第一种是震动传感器。 4 1.4.   第二种是声响传感
    Atitit 架构之道 之 可读性可维护性架构之道 提升效率架构之道 attilax著 艾龙 著 1.1. Hybrid架构 1 1.2. 分层架构是使用最多的架构模式 Layers模式 也称Tie
    Atitit cko之道首席知识官之道 attilax著 艾龙著 1. 2 2. 第 1 章 知识管理到底是什么,有什么用/1 2 3. 1.1 知识管理全景/1 1.2 波士顿矩阵/3 1.2.
    Atitit 提升效率 降低技术难度与提升技术矛盾的解决方案 1. 问题 2 1.1. 高手喜欢技术挑战怎么办,但会提升技术难度 导致新手不会用怎么办 2 2. 解决方案 2 2.1. 通过开会统
    Atitit 依赖管理之道 1. 概念 依赖管理,是指在什么地方以什么形式引入外部代码。 1 1.1.1. 理解模块化和依赖管理: 1 1.2. 依赖管理,有三个层面。 单一职责原则,协议对象引用,
  • 原文地址:https://www.cnblogs.com/fps2tao/p/7831785.html
Copyright © 2020-2023  润新知