git的工做模式和Pull Request用法详解

2019年12月05日 阅读数:24
这篇文章主要向大家介绍git的工做模式和Pull Request用法详解,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

Git的使用

Git的工做方式

分为集中式工做流、功能分支工做流、Gitflow工做流和Forking,其中集中式工做流和功能分支工做流是已经使用过的,Gitflow和Forking两种工做流暂时没有使用过。git

集中式工做流

一个远程仓库,一个主分支master,团队每一个成员都有一个本地仓库,在本地仓库中进行代码的编辑、暂存和提交工做:程序员

git add <some file> 或 git add .>
//`some file`表明要暂存的文件,`.`表明工做目录下的全部文件
gie commit -m "一些描述"
//提交文,描述指的是本次提交修改了什么功能或者修改了什么bug,方便之后的查看
git push -u origin master
//-u选项设置本地分支去跟踪远程对应的分支。设置好跟踪的分支后,就可使用git push命令省去指定推送分支的参数
//发布本地仓库到远程的中央仓库中,origin是远程仓库名,master是参数告诉Git的分支,master表明主分支,固然分支能够不是主分支

注意:在一种状况下push命令会出错,即若是小明第一次发布代码到远程仓库,此时小红在 本地开发本身的功能,那么在小红push本身的本地库到远程的时候会报错,缘由是小红的本地库和远程库有分歧,须要先pull远程库到本地,与本地库合并以后再push到远程库。github

功能分支工做流

在集中式工做流的基础上,为各个新功能分配一个专门的分支来开发,即在master主分支外在建立一个分支,程序员开发的新功能所有push到此分支上,等到功能成熟的时候再把此分支合并到主分支master上web

git checkout -b newbranch master
//checkout表明建立切换带新分支newbranch
//-b表明若是新分支不存在则会建立一个新分支
//最后的master表明新分支是基于主分支建立的

新分支建立以后,对其的编辑、暂存和提交工做与以前同样,对其push的命令变为git push origin newbranch,等到新功能完善以后,经过如下命令:sql

git checkout master
git pull
git pull origin newbranch
git push

首先git checkout master切换到主分支,而后执行git pull把本地仓库的主分支上传到远程库,再执行git pull origin newbranch保证合并newbranch分支和已经和远程一致的本地master分支,你可使用简单git merge newbranch命令,但前面的命令能够保证老是最新的新功能分支。 最后把更新的master分支从新push到远程库。ruby

Gitflow工做流

Gitflow工做流没有用超出功能分支工做流的概念和命令,而是为不一样的分支分配一个很明确的角色,并定义分支之间如何和何时进行交互。
除了有master主分支(用于存储正式发布的历史)外,还有一个做为功能集成分支的develop分支。当初始化完成后,某个程序员想要开发一个性能,并非直接从master分支上拉出新分支,而是使用develop分支做为父分支,当新功能完成后,再合并会父分支,新功能的提交并不与master分支直接交互
Gitflow工做流
一旦develop分支上有了作一次发布(或者说快到了既定的发布日)的足够功能,就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环,因此从这个时间点开始以后新的功能不能再加到这个分支上—— 这个分支只应该作Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工做都完成了,发布分支合并到master分支并分配一个版本号打好Tag。 另外,这些重新建发布分支以来的作的修改要合并回develop分支。ssh

维护分支

维护分支
维护分支或说是热修复(hotfix)分支用于生成快速给产品发布版本(production releases)打补丁,这是惟一能够直接从master分支fork出来的分支。 修复完成,修改应该立刻合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支,让团队能够处理掉问题而不用打断其它工做或是等待下一个发布循环。 你能够把维护分支想成是一个直接在master分支上处理的临时发布。分布式

工做流程

为master分支配套一个develop分支svg

git branch develop
git push -u origin develop

之后这个分支将会包含了项目的所有历史,而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库,建好develop分支的跟踪分支:性能

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

如今每一个开发都有了这些历史分支的本地拷贝。
小红和小明开团队成员始各自的功能开发。他们须要为各自的功能建立相应的分支。新分支不是基于master分支,而是应该基于develop分支:

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上:编辑、暂存、提交:

git status
git add <some-file>
git commit

添加了提交后,功能OK了以后,若是团队使用Pull Requests,这时候能够发起一个用于合并到develop分支。 不然她能够直接合并到她本地的develop分支后push到中央仓库:

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意,功能决不该该直接合并到master分支。 冲突解决方法和集中式工做流同样。

Forking工做流

分布式工做流,充分利用了Git在分支和克隆上的优点,既能够管理大团队的开发者(developer)和接受不信任贡献者(contributor)的提交。这种工做流使得每一个开发者都有一个服务端仓库(此仓库只有本身能够push,可是全部人均可以pull修改),每一个程序员都push代码到本身的服务端仓库,但不能push到正式仓库,只有项目维护者才能push到正式仓库,这样项目维护者能够接受任何开发者的提交,但无需给他正式代码库的写权限。
这种工做流适合网上开源社区的开源项目,你们统一对项目作贡献,可是有一我的或一个团队做为开发者来管理项目,全部的贡献者的代码由开发者审核,其功能完善以后再由开发者push到正式仓库中。

Pull Request

  • Pull Request是一个为讨论提交功能的专门论坛,是一个友好的web界面(在我的github项目中也有这样一个选项),你们在其中作一些Code Review的工做,把结果反馈到Pull Request中,还能够在其中push新的提交微调功能,等到讨论结束后醒目维护者合并全部的功能到官方仓库中,关闭Pull Request。
  • 发起一个Pull Request,就是要请求另外一个开发者来pull本身仓库的一个分支到它的仓库中,所以须要提供四个信息:源仓库、源分支、目的仓库、目的分支。
  • Pull Request能够用于上述除了集中式工做流的其余三种工做流,由于其要求要么分支不一样,要么仓库不一样,而集中式工做流只有一个仓库,一个master分支。
  • 例:在功能分支工做流中使用Pull Request
    功能分支工做流只有一个公开的仓库,因此Pull Request的目的仓库和源仓库老是同一个。 一般开发者会指定他的功能分支做为源分支,master分支做为目的分支。
    收到Pull Request后,项目维护者要决定如何作。若是功能没问题,就简单地合并到master分支,关闭Pull Request。但若是提交的变动有问题,他能够在Pull Request中反馈。以后新加的提交也会评论以后接着显示出来。
    在功能尚未彻底开发完的时候,也可能发起一个Pull Request。 好比开发者在实现某个需求时碰到了麻烦,他能够发一个包含正在进行中工做的Pull Request。 其它的开发者能够在Pull Request提供建议,或者甚至直接添加提交来解决问题。

参考:my-git