东圃那里有做网站设计的怎样建网站?

目录

1.Git工作流

1.1 GitFlow

1.2 Github Flow

1.3 Gitlab Flow

2.Git常用命令

---

随着现代技术的发展，我们代码上库甚至都不需要使用git命令敲敲打打，vscode插件、sourcetree等等这些软件足以帮我们完成日常工作需求。

不过时间久了，基础知识都有些忘了，今天就回顾回顾。

1.Git工作流

工作流这个名字取得挺好，目的就是在多人协作场景下、项目基于工作流可以像水流一样向前推进，不至于发生冲突或者阻塞。

但是，该阻塞的始终会阻塞，因为这个问题确实老大难，每家公司都会以方便自家业务开展为目的进行不同程度的裁剪，但是框架大都基于三类工作流：Gitflow、GitHub Flow、Gitlab Flow。

1.1 GitFlow

这个模型在2010年被提出，时过境迁，经典还是经典。流程如下：

一般来说，Master分支是存放对外发布的分支，相对稳定可靠；Develop分支则是我们日常开发的主分支，存放的是最新的开发版本。

需要注意的是，在这种工作流里，Release Branch实际叫做预发布分支，它是从dev分支拉出，最终需要合并回Dev和Master分支。HotFix与Release Branch类似，但是一般是从Master拉取，去紧急修复发布版本的bug（想起下午发版，晚上就hotfix的痛，哈哈哈）。

该工作流的特点很明显：每个分支干什么非常清晰，但是需要长期维护两个分支--Master和Develop。特别是对于才进公司的萌新，Git命令都还没搞熟，再加上个不同分支切换足以将其搞蒙。

在如今各大公司版本是“持续集成、持续发布”的背景下，这种基于版本发布的工作流无疑增加了开发人员的工作流，特别是有可能Master和Develop本身差别就不是很大的情况。

因此Github Flow就出现了。

1.2 Github Flow

该工作流是一个轻量级的、基于分支的工作流，原文链接如下：GitHub flow - GitHub Docs

它总共就只有一个长期分支Master Branch，所以使用起来就不那么抽象，如下图：

在上述工作流里，我们可以看到只有两个分支，master分支和feature分支。 

Master分支和GitFlow的Master类似，Feature就是开发者的功能分支。

流程也相对简单，项目开始有一个master分支，然后基于该分支拉出新的feature分支进行功能开发，完成开发和测试后需要进行review才能被合入Master，这个Review的过程在Git里叫做Pull Request。

该流程天然就可以服务“持续发布”的产品，但这还是有个问题，假设有些公司他发布版本需要进行审核，但我们的开发仍在每天进行，这时候就无法保证发布版本就是最新的代码，所以一般还需要再创建一个分支来跟踪上线的奔版本。

此外，如果是遇到多人开发的大型项目，解决merge冲突就会把人搞疯。

1.3 Gitlab Flow

GitLab Flow 是一种基于 GitLab 平台的分支管理策略，它是一种结合了 Git Flow 和 GitHub Flow 的工作流程，该流程采用上游优先原则，只存在一个主分支，这也意味着只有上游批准的代码，才会被引入到其他下游分支，同时它还支持多种环境的部署策略，用于应对各种CICD的开发。。

流程图如下：

核心思路还是比较容易理解：Master作为所有分支的上游，使用feature或者hotfix分支来开发功能或者修复bug，需要使用MR(Merge Request)来review代码和测试，并请求合并。合并到master分支的代码可以单独部署到生产环境种，如下：

 这种方式优点很明显，master始终处于可部署状态，适合快速迭代和持续发布的开发环境；但如果是小团队来采取这种，过多的分支管理仍旧会增加复杂性，由于需要稳定的CICD流程，这给小团队增加了部署成本和效率。

2.Git常用命令

首先回顾下Git架构，上一张老图：

Remote repository：远程仓库，所有人共享。

Repository：本地仓库，核心价值在于可以离线操作，它不依赖网络，开发者可在断网环境下提交代码、切换分支或查看历史记录，确保开发流程不中断。

Index：暂存区，文件暂存的地方，作为工作区和本地仓库之间的“缓冲区”，用于临时存放开发者选择提交的代码变更。啥意思呢，就是假设你在开发时被突然打断要切到另外分支区hotfix，就可以暂存起来，避免没有提交的代码消失；或者你开发时只想提交一个功能A，另一个功能继续开发B，也可以把A暂存并提交。

Workspace：工作区，就是你本地文件夹能看到的文件结构，所有的代码操作都在这里完成。

还是举个例子来说明这中间的关系。假设此时项目已经进行了一段时间了，你作为后来者要继续开发，那么整体开发流程一般就是这样：首先clone或者fetch远程仓库到本地电脑，这个时候本地仓库结构和远程仓库结构一致，然后拉个feature分支进行功能开发，完成自测后，先暂存待提交内容到暂存区，然后提交到本地仓库，最后push到远程仓库。

接下来常用的命令汇总如下：

git init： 当前路径下初始化git仓库。
git clone <仓库地址>： 将服务器上的仓库copy到本地电脑上。

git branch <分支名字>： 创建新分支。

git checkout <已有分支名>: 切换到指定的分支。

git add <文件>: 将指定文件暂存到暂存区，准备提交到本地仓库。
git commit -m “log”： 提交暂存的改动，提交带有log信息
git merge <branch_name>： 将指定的分支合并到当前分支。

git push： 将本地仓库提交推送到远程仓库。
git pull： 从远程仓库拉取并合并到当前分支。

git cherry-pick：把某个分支上的独立提交（如 Bug 修复、功能开发）合并到当前分支，避免引入无关代码