关闭

git workflow

时间: 2019-01-08阅读: 1158标签: git

Git与SVN的比较

原理上

  • Git直接记录文件快照,SVN每次提交记录哪些文件更新更新了哪些行
  • Git有本地仓库,SVN没有本地仓库
  • Git大多数是本地操作,SVN大多数操作需要联网

操作上

  • Git先提交到本地仓库然后推送到远程仓库,SVN直接推送到远程仓库
  • Git有各种”反悔”指令,SVN没有
  • Git有真正的branch,而SVN只是工作空间的副本

Gitflow工作流

Gitflow为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互。

历史分支

develop和master是两个常驻分支,master分支记录了正式发布的历史,而develop分支作为功能的集成分支。因此,master分支的每次提交都应分配一个版本号。

功能分支

新的功能分支应该从develop分支迁出一个feature分支,新功能开发完成之后再合并回develop分支,常用命令:

  1. 开发功能a
git checkout -b feature-a develop
  1. 开发完成后合并回develop分支
git checkout develop
git merge --no-ff feature-a
git push
git branch -d feature-a

发布分支

  1. 当开发完成时,直接从develop分支checkout出release分支
 git checkout -b release-0.1 develop
  1. release分支用于发布,发布完成后将release分支合并到master分支并且打标签,方便后续跟踪每次发布。
git checkout master
git merge --no-ff release-0.1
git push

git tag -a 0.1 -m "release 0.1 publish" master
git push --tags

维护分支/热修复

  1. 从master分支拉出一个hotfix分支维护分支用于bug修复、快速给发布版本打补丁
git checkout -b hotfix master
  1. bug修复完成立即合回master分支和develop分支,完成维护后删除hotfix分支
git checkout master
git merge --no-ff hotfix
git push

git checkout develop
git merge --no-ff hotfix
git push 

git branch -d hotfix
  1. master上打新tag
git tag -a 0.2 -m "release 0.2 publish" master
git push --tags

优点

  • 单个功能独立开发,并行开发互不干扰
  • master和develop分支分别记录发布和功能开发的历史
  • 由于有发布分支,其他暂不发布的功能的开发不受发布的影响,可以继续提交
  • 维护分支能快速打补丁,不影响正在开发的功能

缺点

  • 复杂,分支繁多
  • Git GUI不支持,纯命令行
  • 对开发者要求高(理解工作流,熟悉Git命令)
  • 所有功能分支基于不稳定的develop
  • 需要维护两个长期分支master和develop

GitHub Flow

  • 所有在master上的东西都是可发布的(已发布或马上发布)
  • 开发新功能时,从master拉一个名称清晰的新分支
  • 在本地提交到这个分支的同时把它push到远程仓库
  • 当你需要得到反馈或帮助,或者该分支准备merge时,打开一个pull request
  • 该分支被review且同意合并后,合并到master
  • push到master后,应该立即发布

优点

  • 操作简单
  • 主干的代码有质量保证

缺点

  • 测试线和正式环境的发布没有区分

Git-Develop

Git-Develop模式将develop分支作为固定的持续集成和发布分支

  • 每一个功能都从master拉一个功能分支。
  • 在这个功能分支上开发,功能完成到发布时,提交code review,通过后自动合并到develop。
  • 待所有计划发布的变更分支代码都合并到develop后,rebase master到develop,完成发布。
  • 应用发布成功后打一个tag。
  • develop分支的发布版本合并回master。

优点

  • 操作相对简单
  • 流程稍作改动,即可区分测试线和正式环境
  • 每次开发都基于正式版本最新的代码(master),和当前开发的其他分支不产生依赖关系
  • master始终是已发布状态

Pull Requests

Pull requests不是一种工作流,而是一个能让开发者更方便地进行协作的功能,可以在提议的修改合并到正式项目之前对修改进行讨论。

  • 开发者在本地仓库新建一个功能分支。
  • 功能完成后,开发者push分支修改到远程仓库中。
  • 开发者发起Pull requests。
  • 团队成员收到通知,进行code review,讨论和修改。
  • 项目维护者合并功能到仓库中并关闭Pull Requests。

来自:https://sjis.me/post/git_workflow/


站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/1800

关闭

git从远程仓库克隆dev分支到本地的实现

这篇文章主要介绍git从远程仓库拉取dev分支到本地的实现【gitLab】:初始化一个本地仓库、与远程仓库建立连接 、查看本地是否具有dev分支、在本地创建分支dev并切换到该分支 、dev分支上的内容都拉取到本地

使用 Git 来管理 Git 服务器

这涉及除日常使用 Git 之外的许多组件,其中最重要的是 Gitolite,该后端应用程序可以管理你使用 Git 的每个细微的配置。Gitolite 的优点在于,由于它使用 Git 作为其前端接口,因此很容易将 Git 服务器管理集成到其他基于 Git 的工作流中

git同步源码到gitee和github

如何把我们的源码同步到gitee或github远程仓库中,同步方式分以下几种:先查看下我们是否有远程仓库:git remote -v,如有就要删除远程仓库或是同命令覆盖,如全新安装就不需要!

采用GitOps的11大原因

Kubernetes允许我们单纯地使用声明性的配置文件来管理我们的应用部署和其他基础设施组件(例如,我们现在都是YAML开发者)。这使我们能够把所有这些文件放到Git仓库中

GIT分支管理:创建与合并分支、解决合并冲突

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

Git忽略文件不起作用的解决方法

开发过程中,我们自己会在gitignore 文件中添加一些忽略项,然而,每次使用git status 的时候都未列在 untracked里面,比如 用IDEA 开发,.idea 文件夹添加到该文件,再提交还是会提示。

最常见的 Git 错误都有哪些,如何解决它们?

如果您曾经与许多开发者一起开发一个大项目,那么使用 Git 作为版本控制是一个最好的选择。 不过 Git 很复杂,使用过程中经常会犯各种错误。 在本文中,我将讨论程序员在使用Git时所犯的一些常见错误以及如何解决它们

Git忽略规则文件.gitignore_关于.gitignore配置

.gitignore 文件的作用就是告诉git, push的时候忽略指定的文件夹或者文件,例如:vue-cli脚手架创建的项目,push到github上时,不会上传node依赖文件夹,这是因为vue-cli脚手架创建的时候,自动为我们创建了 .gitignroe文件,并且为我们写好了规则。

git commit报错

在终端输入git commit -am \\\"**\\\",提交代码时,会触发pre-commit的钩子,他会在Git提交信息之前先做代码风格的检测,如果不符合相应规则,会报错

git全局忽略设置和.gitignore

在使用git过程中,希望git忽略某些特殊文件或文件夹,避免提交例如.DS_Store等等。先来查看一下git状态:如果只是这一个项目中有部分不需要提交的内容,那么直接在项目最外层创建一个.gitignore

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!