首页 > git 打tag_图文讲解，团队开发中的 Git 最佳实践

git 打tag_图文讲解，团队开发中的 Git 最佳实践

私信我，回复：学习，获取免费学习资源包。

在 2005 年的某一天，Linux 之父 Linus Torvalds 发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程，大大地提高了开发流畅度！直到现在仍十分流行，完全没有衰退的迹象。

本文不是一篇 Git 入门教程，这样的文章一搜一大把，我是要从具体实践角度，尤其是在团队协作中，阐述如何去好好地应用 Git。既然是讲在团队中的应用实践，我就尽可能地结合实际场景来讲述。

c1b4bdd5bfa58f565cad765051783f1b.png

习惯养成

如果一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用 Git 时需要自己养成良好的习惯。

提交

如何去写一个提交信息，《Git: 教你如何在Commit时有话可说》中做了很好的说明。在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」，只要坚持做到以下几点就 OK 了：

  1. 提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
  2. 用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
  3. 不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。

假如已经把代码提交了，对这次提交的内容进行检查时发现里面有个变量单词拼错了或者其他失误，只要还没有推送到远程，就有一个不被他人发觉你的疏忽的补救方法——

首先，把失误修正之后提交，可以用与上次提交同样的信息。

97b98e8cf8c7dc037830d5d4e53a8666.png

然后，终端中执行命令 git rebase -i [SHA]，其中 SHA 是上一次提交之前的那次提交的，在这里是 3b22372。

e8495e5acb9e3260febb8d4b446110ee.png

最后，这样就将两次提交的节点合并成一个，甚至能够修改提交信息！

d82a1fc65812ba376d9d70225c98e4cc.png

谁说历史不可篡改了？前提是，想要合并的那几次提交还没有推送到远程！

推送

当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。

拉取

请读张文钿所写的《使用 git rebase 避免無謂的 merge》。

合并

在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。

分支管理

Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性，团队中如果没有一个成熟的分支模型的话，那将会是一团糟。

2fc6e2f9de3e9b96c3b00b91e69fdd27.png

要是谁真把这么乱的提交图表摆在我面前，就给他一个上勾拳！

分支模型

有个很成熟的叫「Git Flow」的分支模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。

需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。

简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：

  • master——最为稳定功能最为完整的随时可发布的代码；
  • hotfix——修复线上代码的 bug；
  • develop——永远是功能最新最全的分支；
  • feature——某个功能点正在开发阶段；
  • release——发布定期要上线的功能。

看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：

8800b9912dd84eeffa3028aa8a0b09be.png

更多信息可参考 xirong 所整理的《Git工作流指南》。

工具选择

一直不喜欢「＊＊最好用」这种命题，主观性太强，不会有一个结论。对于工具的选择，我一直都是秉承「哪个能更好地解决问题就用哪个」这个原则。所以，只要不影响到团队，用什么工具都是可以接受的。但根据多数开发人员的素质情况来看，建议使用图形化工具，例如 SourceTree。如果想用命令行，可以啊！先在心里问下自己：「我 Git 牛逼不？会不会惹麻烦给别人？」

在团队中应用 Git Flow 时，推荐使用 SourceTree 与 GitLab 配合的形式：

  1. 用 SourceTree 创建 feature 等分支以及本地的分支合并、删除；
  2. 用 GitLab 做代码审核和远程的分支合并、删除。

SourceTree 和 GitLab 应该是相辅相成的存在，而不是互相取代。

事前准备

为了将一些规范性的东西和 Git Flow 的部分操作自动化处理，要对 SourceTree 和 GitLab 进行一下配置。

SourceTree

按下 command + , 调出「Preferences」界面并切换到「Git」标签，勾选「Use rebase instead of merge by default for tracked branches」和「Do not fast-forward when merging, always create commit」。

e92c9689db111d67cb8ef69de09a8b47.png

这样设置之后，在点「Pull」按钮拉取代码时会自动执行 git pull --rebase；并且，每次合并时会自动创建新的包含分支信息的提交节点。

接下来，点击工具栏中的「Git Flow」按钮将相关的流程自动化。如果没有特殊需求，直接按下对话框中的「OK」就好了。初始化完成后会自动切换到 develop 分支。

b2f68cbb6100d188b78a203754b272a2.png

这下再点「Git Flow」按钮所弹出的对话框就是选择创建分支类型的了。

GitLab

在创建项目仓库后一定要把主要分支，也就是 master 和 develop 给保护起来。为它们设置权限，只有项目负责人可以进行推送和删除等操作。

0dd68dc5d7b9eed7a3a9d8019bc1c41c.png

被保护的分支在列表中会有特殊的标记进行区分。

开发流程

在引入 Git Flow 之后，所有工作都要围绕着它来展开，将原本的流程与之结合形成「基于 Git Flow 的开发流程」。

b2f99839943d890077bd95aced7c3841.png

开发功能

在确定发布日期之后，将需要完成的内容细分一下分配出去，负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话，创建分支并做一些初始化工作之后就推送创建远程分支；否则，直到功能开发完毕要合并进 develop 前，不要创建远程分支。

功能开发完并自测之后，先切换到 develop 分支将最新的代码拉取下来，再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」，如果有冲突则自己和配合的人一起解决。

然后，到 GitLab 上的项目首页创建合并请求(merge request)。

ba8688b972e3efc6343f323d8c3b5ddd.png

「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮，在出现的表单中将处理人指派为项目负责人。

ce35fa4201b7d8ab75d6a89cc841c4ab.png

项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。

402f4d1d4b4918ba2879be5fe316304d.png

在将某次发布的所需功能全部开发完成时，就可以交付测试了。

测试功能

负责测试的人创建一个 release 分支部署到测试环境进行测试；若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。

发布上线

当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。

建议打 tag 时在信息中详细描述这次发布的内容，如：添加了哪些功能，修复了什么问题。

修复问题

当发现线上环境的代码有小问题或者做些文案修改时，相关开发人员就在本地创建 hotfix 分支进行修改，具体操作参考「开发功能」。

如果是相当严重的问题，可能就得回滚到上一个 tag 的版本了。

额外说明

这里所提到的事情，虽非必需，但知道之后却会如虎添翼。

分支命名

除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就要有个命名规范了。强烈推荐用如下形式：

  • feature——按照功能点(而不是需求)命名；
  • release——用发布时间命名，可以加上适当的前缀；
  • hotfix——GitLab 的 issue 编号或 bug 性质等。

另外还有 tag，用语义化的版本号命名。

b4ce67a48cd7b864871f9fdd410826a9.png

发布日期

发布频率是影响开发人员与测试人员的新陈代谢和心情的重要因素之一，频繁无规律的发布会导致内分泌失调、情绪暴躁，致使爆粗口、砸电脑等状况出现。所以，确保一个固定的发布周期至关重要！

在有一波或几波需求来临之时，想挡掉是不太可能的，但可以在评审时将它(们)分期，在某个发布日之前只做一部分。这是必须要控制住的！不然任由着需求方说「这个今天一定要上」「那个明天急着用」的话，技术人员就等着进医院吧！

来源网络，侵权联系删除

私信我，回复：学习，获取免费学习资源包。

更多相关：

  • Git 简介1-常用术语

    常用术语 1. origin origin是对项目最初克隆(clone)的远程仓库的缩写。 更准确地说，origin 是用来代替原始(original)远程仓库的URL, 从而使在git 命令中使用原始仓库更加容易。 2. master master 是分支的命名约定。 从远程服务器克隆后，生成的本地存储库只有一个本地分支...

  • git---远程仓库版本回滚

    开发中，发现有错误版本提交带远程分支master，怎么处理？ 1 简介 最近在使用git时遇到了远程分支需要版本回滚的情况，于是做了一下研究，写下这篇博客。 2 问题 如果提交了一个错误的版本，怎么回退版本？ 如果提交了一个错误的版本到远程分支，怎么回退远程分支版本？ 如果提交了一个错误的版本到公共远程分支，又该怎么回退版本？ 3...

  • Git简明手册

    文／AbnerKang（简书作者）原 文链接：http://www.jianshu.com/p/d7a7ba4f2341?utm_campaign=maleskine& utm_content=note&utm_medium=reader_share&utm_source=weixin&from=timeline&isappins...

  • git 从远程主服务器当中创建新分支

    现有版本; h20, h28，h26,i8 h28，h26,i8是从H20下面创建的。 需求: 从H28下面创建新分支继续开发。 思路：       所有代码均是放置到H20上仓库当中，首先下载H20完整仓库，也就是.git文件夹当中内容，其本质是一个ZIP文件。 然后从仓库当中取出某一个分支（如H28)，这就是同步到某个分支的所有代...

  • java防止表单重复提交

    看了网上的，有几种方法： 1 在你的表单页里HEAD区加入这段代码:   

  • frps server端配置_Docker 快速搭建 mock-server

    项目目前选型是前后端分离开发，其中前端使用 AntDesign pro。根据和一线工程师沟通，引入 mock 技术搭建 json-server，可以快速模拟调用后端接口，实现增删查改以及复杂的业务逻辑。不用等后端开发完毕，配合 rap2 接口管理系统，前后端统一约束，而且前端不用手工造数：可以从配置好正则的接口生成（来自 rap2 接...

  • 用Unity的视频广告创建2D动作游戏 Create Action 2D Game With Video Ads In Unity

    MP4 |视频:h264，1280×720 |音频:AAC，44.1 KHz，2 Ch 语言：英语+中英文字幕（根据原英文字幕机译更准确） |时长:27场讲座(4h 19m) |大小解压后:2.35 GB Unity 2D游戏开发终极指南 你会学到: 学习使用Unity TileMap绘制您的世界 掌握初学者C#概念，包括sin...

  • 构建之法-读后感

    大二快结束，从大二初开始接触项目的工程开发，到现在也差不多一年了。之前一直在用c# 结合winform开发一些简单的桌面应用，也看过一些是实验室学长们用c#和其他多种技术结合 开发出来的系统， 接触过其源代码，为深入了解也曾阅读过试着了解内部实现的机制。在进行项目开发之前，带着我们的学长一直在和我们强调编程规范的重要性，并且给我们分析...

  • Android深度探索(卷1)HAL与驱动开发第五章总结

    开发板是开发和学习嵌入式技术的主要硬件设备，开发板的型号和种类很多，目前流行的是基于S3C6410 ARM11架构的开发板，S3C6410是由三星公司推出的一款低功耗，高性价比的RISC处理器，它基于ARM11内核，可广泛应用于移动电话和通妖魔化处理等领域。OK6410开发板基于三星公司最新的ARM11处理器S3C6410，拥有强大...

  • 《梦断代码Dreaming In Code》阅读笔记（三）

          最后这几章感觉上更多是从软件完成整体上来讲的。比如说技术、方法等。       在我看来，其实一个团队一直坚持一种好的、先进的方法是不可少的。如果一个优秀的团队刚愎自用，只随着成员们喜好发展，那不能长久。比如说，在开发软件工程课程的大项目时，我们团队也在学习着敏捷开发方法，虽然我们没有严格按照它的形式或流程，但是我们运用了...

©2024 11GX.COM