解释：git其实是用来存储代码的开源仓库，通过给当前仓库下的用户分配不同的角色：管理员、开发者、测试等来区分权限；
大家好，我是山月，这是我最近新开的专栏：「前端部署系列」。包括 Docker、CICD 等内容，大纲图示如下：
当前git是大部分开发团队的首选版本管理工具，一个好的流程规范可以让大家有效地合作，像流水线一样有条不紊地进行团队协作。
一般一个项目部署的环境至少有本地环境、dev开发环境、fat环境、线上环境，只是最最基本的几个环境。
在AI辅助编程飞速发展的时代，健全的DevOps实践显得尤为重要。本博客将演示如何在构建和增强CI/CD流水线中高效利用AI，并强调虽然AI带来重大进步，但人的专业知识仍不可替代。
master 分支 不能往master 分支上提交代码，只能在该分支上进行代码合并操作，例如将其它分支的代码合并到 Master 分支上。 develop 分支 我们日常开发中的代码需要从 master 分支拉一条 develop 分支出来，该分支所有人都能访问，但一般情况下，我们也不会直接在该分支上提交代码，代码同样是从其它分支合并到 develop 分支上去。 feature 分支 当我们需要开发某个特性时，需要从 develop 分支拉出一条 feature 分支，例如 feature/update_mq 与 feature/update_netty，在这些分支上并行地开发具体特性。 release 分支 当特性开发完毕后，我们决定需要发布某个版本了，此时需要从 develop 分支上拉出一条 release 分支，例如 release-1.0.0，并将需要发布的特性从相关 feature 分支一同合并到 release 分支上，随后将针对 release 分支推送到测试环境，测试工程师在该分支上做功能测试，开发工程师在该分支上修改 bug。待测试工程师无法找到任何 bug 时，我们可将该 release 分支部署到预发环境，再次验证以后，均无任何 bug，此时可将 release 分支部署到生产环境。 tag 待上线完成后，将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag，例如 v1.0.0。 hotfix 当生产环境发现 bug 时，我们需要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上做 bug 修复。待 bug 完全修复后，需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。同时在master上打上tag，v1.0.1。 版本号 对于版本号我们也有要求，格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。 个人分支 个人分支下可以建目录，例如: xiaoguai/dev1, xiaoguai/dev2
在开发过程中，遵循一个合理、清晰的GIT使用流程，是至关重要的。否则，每个人都提交一堆杂乱无章的commit,会增加后期协调和维护的复杂度。
部署过程需要用到一些Linux命令,且本文部署操作机为Mac,如是Windows不保证能100%成功噢
Serverless Framework Pro 版是个 SaaS 应用，是个托管的 Dashboard。
在实际中，需要多分支同时进行开发。如果每个分支都创建一个Jenkins项目，比较多余。创建选择 Multibranch Pipeline
相信不少人最听说过 Github 部署网站，但是我翻找了很多文章基本以实操为主，在 Setting 点一下就没了。
在这之前，没有自己配置过Jenkins，都是照猫画虎，Copy原来已经配好的项目过来修修改改，一直想不明白比如BUILD_NUMBER之类的东西是哪来的(其实是没有找到官方说明)，很纳闷，今天找到了，然后就详细写一遍，记录学习一下。
2019年2月13日更新*：本文的最初版本引起了很大的反响，大多数是正面的，有些则不是。争论的焦点在于我们在包含手动组件的环境中使用了“持续交付”这个术语。如果你所在的团队每天需要部署数百个版本，那么我们的框架可能不适合你。但是，如果你身一个像我们这样的受到严格监管的行业，例如财务行业，在这里版本控制更加严格，并且你希望充分利用功能分支、自动化集成、自动化部署和版本控制，那么这个解决方案可能对你同样有效。*
当我们谈论git时，我们首先会想到版本控制和各种命令及概念。git基础操作请看我的另外一篇文章【操作】git版本控制流入门命令FQ#1
今天照常开发，在日常部署测试的时候进行git merge 竟然出现了"代码丢失"的情况，相当诡异，特此记录。
好几个月没发帖子了，开始了产生懒惰情绪，挺羡慕能持续输出的同学，一直保持高质量输出。其实最近这几个月，做的东西偏效能方向,提供给开发、测试、项目管理使用，大部分时间是全职开发。其中有很多需求来自开发同学，通过平台化建设提高他们的工作效率。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
Git 作为一个源码管理系统，不可避免涉及到多人协作。 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
因为是主线上的bug，所以先切回到主线上去，不过本地的主线可能有点旧了，所以把本地的master分支删掉，然后和远端同步一下之后再从远端把master分支检出
很多读者看了《从9G到0.3G，腾讯会议对他们的git库做了什么？》之后，希望鹅厂程序员们分享更多 git 操作技巧。”git坑太多了“、”在工作中我经常遇到这个情况：忙了一天准备提交代码下班，结果 git 合并冲突把刚写好的代码覆盖掉了，血压飙升！““合并前文件还在的，合并后就不见了”，“我遇到 git 合并的 bug 了” ——这是程序员高频遇到的场景。鹅厂毕鸣一如何攻破这个 git 使用时的痛点？欢迎继续阅读。
Deployer 是一个基于 SSH 协议的无侵入 web 项目部署工具，因为它不需要你在目标服务器上装什么服务之类的东西即可使用，它的原理就是通过 SSH 到你的机器去创建目录，移动文件，执行指定的动作来完成项目的部署。他支持多种框架：Laravel、Yii等
最开始接触博客的契机是我第一次重装Ubuntu的时候。看的是楠皮的博客，之后又重装了7次Ubuntu，每次都去看楠皮的博客，一个人撑起了他的博客访问量。自此，我终于意识到我也该写个博客了，一开始用到的是csdn，虽然csdn自带的网页markdown非常方便，还有快捷键支持，但是实在是架不住那边烦人的站点广告，之后也试过简书，虽然好看了许多，但是还是没有我当初浏览楠皮博客时那种丝般顺滑的感觉。
gitee相比github访问速度更快，但是Gitee Pages服务需要实名制认证。
如果一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用 Git 时需要自己养成良好的习惯。
如下图所示，根据需要配置构建信息 添加github的Token到环境变量中，用户名，邮箱也可添加进去，这样配置文件中就可以使用了 生成Token见步骤5.注意：配置私密的环境变量时一定要加密，因为会显示在日志中且能够被他人看到
与github一样，Gitee也是一个基于 Git 的代码托管服务站。而且与github的联动非常好，可以直接通过Gitee导入Github的仓库，然后使用Gitee的仓库来git clone项目，之后再重新设置远程仓库链接，将修改push到Github上。下次又需要git clone的时候，只要确定Gitee的仓库拉取了最新修改即可。这也是我一度将Gitee称之为工具人的原因。
如何去写一个提交信息，在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」，只要坚持做到以下几点就 OK 了：
本文要从具体实践角度，尤其是在团队协作中，阐述如何去好好地应用 Git。既然是讲在团队中的应用实践，我就尽可能地结合实际场景来讲述。
本文转载自：https://segmentfault.com/a/1190000004963641[1]
在 2005 年的某一天，Linux 之父 Linus Torvalds 发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程，大大地提高了开发流畅度！直到现在仍十分流行，完全没有衰退的迹象。
相信绝大部分的人都会直接 pull，偶尔 fetch。但是这 2 个到底有什么不同呢？
提交消息规范是在使用Git进行版本控制时的一项最佳实践，它有助于组织和标准化提交消息，使团队更容易理解和管理项目的变更历史。以下是关于Git提交消息规范的最佳实践：
版本控制系统提供了能够满足以上需求的工具。Git 是版本控制系统的典范，而 GitHub 是一个为个人或团队操作 Git 储存库 ( Git Repositories) 提供了 Git 服务器和一系列非常实用的工具的网站 + 基础设施。它提供了报告代码错误、检查工具以及分配任务和任务状态等项目管理工具等等。
在GIT中，分支（Branch）管理是一项重要的功能，它允许你在不影响主要项目代码的情况下，进行独立的开发工作或实验性工作。以下是如何创建和切换分支的步骤：
其实我一开始最先尝试的就是Ubuntu上搭建，但是，非常遗憾的是，Ubuntu的各种读写权限把我弄得死去活来。 毕竟一开始看的就是楠皮的博客来尝试的，后来发现没什么大用，不够详细倒是其次，主要是缺乏他其他几篇博客那样的普适性。怎么说呢，我花了三天时间踩坑，终于算是可以正常使用并且和Win10完美同步了。 所以之后写的内容里有很多都会附加上我踩坑时的怨念。
上一篇文章中我们提到了在一个周维度或者月维度发布产品的小型协作项目中，会遇到各类协作上的问题，随着发布的越来越紧凑，问题也就越来越突出。本文主要对上一篇文章中提到的问题解决方案做细化，让大家可以清楚的知道如何通过合理的 git 工作流来解决这些问题，让原来发布时的手忙脚乱不再出现。通过 git flow 我们可以对项目做一个分支模型管理：
现代软件开发过程中要实现高效的团队协作，需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具，包括CVS，SVN，Git，Mercurial等。
个人比较喜欢 git add -p. 这增加了“补丁模式”的变化，这是一个内置的命令行程序。它遍历了每个更改，并要求确认是否要执行它们。
使用 Git 的最佳方式一直存在争议。那是因为 Git 本身只详细说明了基本的分支操作，这使得它的使用模式: 即分支模型——常常成为用户有意见的地方。虽然Git 分支模型能够帮助开发者减少其在更改代码库时带来的冲突。
当学习GIT的基本概念时，理解仓库（Repository）、提交（Commit）、分支（Branch）和合并（Merge）是至关重要的。这些是IT的核心概念，对于有效使用GIT非常关键。
安装最新版git可以去Git的官网，从Git官网直接下载安装程序，然后按默认选项安装即可。
Github上我们经常fork其他人的代码，然后经过一通魔改后弄出"自己"的东西。但是现在我遇到了这么一个需求，就是我已经公开了一个自己的库(暂且叫parent)，然后我想基于自己开发的库再创建新的功能，但是又不想让新功能公开，一个很自然的想法是库parent保持公开，然后新创建一条分支隐藏，可惜的是github并不支持这个功能。所以一个可行的办法就是fork自己的库，但是不是直接fork，因为你也没法fork自己的库，间接实现的方法如下：
常见的Git类代码分支模型有Git flow、Github flow、Gitlab flow、TBD等，企业可根据其业务、团队、管控等多方因素，选用其中一种或多种代码分支模型，随着DevOps工具的引入，在不降低代码质量管控力度的同时可有效提升代码管控效率，代码分支模型的应用可更加灵活自主。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
