前端核心

Git

1. git 和 svn 的区别

  • git 和 svn 最大的区别在于 git 是分布式的，而 svn 是集中式的。因此我们不能再离线的情况下使用 svn。如果服务器出现问题，就没有办法使用 svn 来提交代码。
  • svn 中的分支是整个版本库的复制的一份完整目录，而 git 的分支是指针指向某次提交，因此 git 的分支创建更加开销更小并且分支上的变化不会影响到其他人。svn 的分支变化会影响到所有的人。
  • svn 的指令相对于 git 来说要简单一些，比 git 更容易上手。
  • GIT 把内容按元数据方式存储，而 SVN 是按文件：因为 git 目录是处于个人机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
  • GIT 分支和 SVN 的分支不同：svn 会发生分支遗漏的情况，而 git 可以同一个工作目录下快速的在几个分支间切换，很容易发现未被合并的分支，简单而快捷的合并这些文件。
  • GIT 没有一个全局的版本号，而 SVN 有
  • GIT 的内容完整性要优于 SVN：GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏

2. 经常使用的 git 命令？

git init                     // 新建 git 代码库
git add                      // 添加指定文件到暂存区
git rm                       // 删除工作区文件，并且将这次删除放入暂存区
git commit -m [message]      // 提交暂存区到仓库区
git branch                   // 列出所有分支
git checkout -b [branch]     // 新建一个分支，并切换到该分支
git status                   // 显示有变更文件的状态
1、git init：初始化一个Git仓库；
2、git clone：从远程仓库克隆代码到本地；
3、git add：添加文件到暂存区；
4、git commit：将暂存区的文件提交到本地仓库；
5、git push：将本地仓库的代码推送到远程仓库；
6、git pull：从远程仓库拉取最新代码；
7、git branch：列出所有本地分支；
8、git checkout：切换分支或恢复工作树文件；
9、git merge：合并指定分支到当前分支；
10、git status：显示工作树的状态；
11、git log：显示提交日志；
12、git diff：显示工作树与暂存区或本地仓库之间的差异；
13、git stash：将当前工作区的变更储存到一个临时区域；
14、git tag：添加、列出或删除标签；
15、git remote：管理远程仓库；
16、git fetch：从远程仓库拉取最新代码，但不自动合并到本地仓库；

3. git pull 和 git fetch 的区别

  • git fetch 只是将远程仓库的变化下载下来，并没有和本地分支合并。
  • git pull 会将远程仓库的变化下载下来，并和当前分支合并。

4. git rebase 和 git merge 的区别

git merge 和 git rebase 都是用于分支合并，关键在 commit 记录的处理上不同：

  • git merge 会新建一个新的 commit 对象，然后两个分支以前的 commit 记录都指向这个新 commit 记录。这种方法会保留之前每个分支的 commit 历史。
  • git rebase 会先找到两个分支的第一个共同的 commit 祖先记录，然后将提取当前分支这之后的所有 commit 记录，然后将这个 commit 记录添加到目标分支的最新提交后面。经过这个合并后，两个分支合并后的 commit 记录就变为了线性的记录了。

参考网址：https://www.jianshu.com/p/f23f72251abc

Description

git rebase 和 git merge 一样都是用于从一个分支获取并且合并到当前分支，但是他们采取不同的工作方式，以下面的一个工作场景说明其区别

场景：

如图所示：你在一个 feature 分支进行新特性的开发，与此同时，master 分支的也有新的提交。

img

为了将 master 上新的提交合并到你的 feature 分支上，你有两种选择：merging or rebasing

merge

执行以下命令：

git checkout feature
git merge master

或者执行更简单的：

git merge master feature

那么此时在 feature 上 git 自动会产生一个新的 commit(merge commit) look like this：

img

marge 特点：自动创建一个新的 commit 如果合并的时候遇到冲突，仅需要修改后重新 commit 优点：记录了真实的 commit 情况，包括每个分支的详情 缺点：因为每次 merge 会自动产生一个 merge commit，所以在使用一些 git 的 GUI tools，特别是 commit 比较频繁时，看到分支很杂乱。

rebase

本质是变基 变基 变基 变基是什么? 找公共祖先 共同祖先是什么? 详见参考资料 2、3 官方的文章

执行以下命令：

git checkout feature
git rebase master

look like this:

img

rebase 特点：会合并之前的 commit 历史 优点：得到更简洁的项目历史，去掉了 merge commit 缺点：如果合并出现代码问题不容易定位，因为 re-write 了 history

合并时如果出现冲突需要按照如下步骤解决

  • 修改冲突部分
  • git add
  • git rebase --continue
  • （如果第三步无效可以执行 git rebase --skip）

不要在 git add 之后习惯性的执行 git commit 命令

The Golden Rule of Rebasing rebase 的黄金法则
never use it on public branches(不要在公共分支上使用)

比如说如下场景：如图所示

img

如果你 rebase master 到你的 feature 分支：

rebase 将所有 master 的 commit 移动到你的 feature 的顶端。问题是：其他人还在 original master 上开发，由于你使用了 rebase 移动了 master，git 会认为你的主分支的历史与其他人的有分歧，会产生冲突。

所以在执行 git rebase 之前 问问自己，

会有其他人看这个分支么？ if YES 不要采用这种带有破坏性的修改 commit 历史的 rebase 命令 if NO ok，随你便，可以使用 rebase

Summary 总结

如果你想要一个干净的，没有 merge commit 的线性历史树，那么你应该选择 git rebase 如果你想保留完整的历史记录，并且想要避免重写 commit history 的风险，你应该选择使用 git merge

5. Git Flow

参考：https://blog.csdn.net/sunyctf/article/details/130587970

Git Flow 是一种使用 Git 进行软件开发的模型，它定义了一个清晰的角色分工，用于管理不同类型的发布周期（比如功能开发、发布准备、热修复等）。以下是 Git Flow 的基本步骤和命令示例：

初始化新仓库：

git init

开始新功能开发：

git checkout -b feature/new-feature develop

完成功能开发后，将改动合并回 develop 分支：

git checkout develop
git merge --no-ff feature/new-feature
git branch -d feature/new-feature
git push origin develop

准备发布（基于 develop 分支创建 release 分支）：

git checkout -b release/1.0.0 develop

测试完成后，准备合并到 master 分支并为 master 打标签：

git checkout master
git merge --no-ff release/1.0.0
git tag -a 1.0.0
git branch -d release/1.0.0
git push origin master
git push origin --tags

将 develop 分支的更改合并回 master 分支：

git checkout develop
git merge --no-ff master
git push origin develop

修复生产环境的紧急问题（基于 master 分支创建 hotfix 分支）：

git checkout -b hotfix/1.0.1 master

修复完成后，合并到 master 分支并再次为 master 打标签：

git checkout master
git merge --no-ff hotfix/1.0.1
git tag -a 1.0.1
git branch -d hotfix/1.0.1
git push origin master
git push origin --tags

将更改从 master 分支合并回 develop 和相应的生产分支：

git checkout develop
git merge --no-ff master
git push origin develop

以上步骤和命令提供了 Git Flow 的概览，实际操作时需要根据项目具体情况进行调整。

6.git代码合并，遇到冲突是怎么解决冲突的

在Git中合并代码（如使用git merge或git pull命令时）遇到冲突是一个常见的情况，尤其是在多人协作的项目中。解决这些冲突需要一定的步骤和技巧。下面是一个基本的流程来解决Git中的合并冲突：

1. 识别冲突

当你执行合并操作（如git merge或git pull）并遇到冲突时，Git会停止合并过程，并告诉你哪些文件存在冲突。冲突的文件会包含特殊的标记，如<<<<<<<、=======和>>>>>>>，这些标记之间的内容代表不同分支中的冲突内容。

2. 手动解决冲突

  • 打开冲突文件：使用你偏好的文本编辑器或IDE打开冲突的文件。
  • 查看冲突内容：寻找由<<<<<<<、=======和>>>>>>>标记的冲突区域。
  • 选择内容：根据你的需求和项目情况，决定保留哪些内容。你可以完全删除一些部分，或者合并它们。
  • 删除标记：确保删除所有冲突标记（<<<<<<<、=======和>>>>>>>）。

3. 标记冲突为已解决

解决完所有冲突后，你需要告诉Git这些冲突已经被解决了。这通常是通过简单地添加（git add）冲突的文件来完成的。Git通过这种方式来跟踪文件的修改状态。

bash复制代码

git add <冲突的文件名>

对于多个冲突文件，你需要对每个文件都执行这个命令，或者你可以使用.来添加所有已修改的文件（包括已解决冲突的文件）：

bash复制代码

git add .

4. 完成合并

一旦所有冲突都被标记为已解决，你可以继续完成合并过程。如果你是在执行git merge时遇到冲突的，可以直接继续：

bash复制代码

git commit

Git会提示你输入一个合并提交的说明。这通常是一个好机会来简要说明为什么这次合并是必要的，以及你是如何解决冲突的。

如果你是在执行git pull时遇到冲突的，git pull实际上是git fetch和git merge的结合。在解决完冲突后，你可能需要手动完成合并提交，或者如果你的Git配置是rebase而不是merge（通过git config --global pull.rebase true设置），你可能需要执行git rebase --continue来继续拉取过程。

5. 验证和测试

最后，不要忘记在解决完所有冲突后，重新运行你的测试套件来确保你的更改没有引入新的问题。

通过遵循上述步骤，你应该能够有效地解决Git中的合并冲突。记住，保持冷静和耐心是关键，因为复杂的冲突可能需要一些时间来仔细处理。

7. git命令如何回退版本

要回退到之前的版本，可以使用以下命令：

  1. 使用 git log 查看历史版本的 commit ID
  2. 使用 git reset --hard <commit ID> 回退到指定的 commit ID
  3. 使用 git push origin <branch> --force 将本地的回退结果推送到远程仓库（注意：使用 --force 会覆盖远程仓库的历史记录，谨慎使用）

如果只是想撤销最近一次的 commit 操作，可以使用以下命令：

  1. 使用 git log 查看最近一次的 commit ID
  2. 使用 git reset --hard HEAD^ 回退到上一个 commit
  3. 使用 git push origin <branch> --force 将本地的回退结果推送到远程仓库（同样需要注意 --force 的使用）

以下为更详细的说明：

一、查看commit-id（哈希码）

与回退息息相关的是commit-id，也就是哈希码，如何得到这个commit-id呢？ 两种写法，如下所示：

第一种：

git log // 四行详细记录，包括的信息有commit-id、提交者、提交时间、备注

第二种：

git log --pretty=oneline  //输出的每个提交记录只占据一行，每行的显示内容为commit-id + 备注

二、回退到指定的版本，并保留更改

通过git log查看id，最上方的就是最新的提交记录，应该会出现你提交错误的那条记录，下面开始进行回退：

1、回退到指定版本，这个方法回退比较灵活，可以选择回退到指定的记录。

git reset <commit-id>

//<commit-id>写你想要回退到的那个版本的id，不要选择最新的，如果选择最新的则没回退有效果。
//<commit-id>后面的提交记录都会被删除，但是不会删除代码，会把代码放在暂存区。

2、快捷回退上一版本，没有特殊，只是回到上一次。 如果要回退到上一个版本，可以使用以下 Git 命令，此命令也会保留更改，不会删除代码，会把代码放在暂存区：

git reset HEAD^

这个命令将会将当前版本回退到上一个版本，HEAD^ 表示上一个版本，HEAD^^表示上上个版本。

如果想回退更多个版本，用 HEAD~n 即可，比如回退到前5个版本：

git reset HEAD~5

三、回退到指定版本，不保留更改

回退的同时，将代码和commit记录都将回退到指定版本，放弃目标版本以后的所有修改，灵活回退，但是不会保留代码。

git reset --hard <commit-id>

四、回退到指定版本，保留commit记录

该命令会回退指定版本的修改，撤销文件后不会影响其他的提交。

// 撤销某个提交，并创建一个新的提交。
git revert <commit-id>
// 撤销某个提交，但执行命令后不进入编辑界面，也就是不会自动帮你提交文件，需要手动提交
// 这与第1点的差别就是撤销和提交分开了。
git revert --no-commit <commit-id>

参考网站：https://blog.csdn.net/weixin_58951442/article/details/137506760

参考网站：https://www.yisu.com/ask/23166620.html

8. 合并某一个分支中的某一次提交

问题： 在我们开发过程中，有两个分支A、B，通常在A分支上开发的东西想要合并到B分支，运用命令git merge B即可完后完成合并，此操作将把A分支上的所有新增代码合并到B分支上，如果只想将某次提交的功能移到B分支，该如何操作呢？ 解决： 1、在A分支上查看提交记录，获取提交记录的id

git log --oneline A

2、拿到id后，切换到B分支,合并A分支某个提交

git cherry-pick da099c9b

3、执行该命令后，Git 将把该提交应用到 B分支上，而不会合并 A分支的其他提交。

备注：如果有冲突，需要在文本编辑器自行解决冲突，解决冲突后可以使用

git cherry-pick --abort

9. git 提交代码需要注意什么

在提交Git代码时，需要注意以下几个方面‌：

  1. ‌提交信息清晰明了‌：提交信息应该简短明了，不超过50个字符，并使用命令式语言。例如，“Add feature X”、“Fix bug Y”等。提交信息需要简明扼要地描述提交的目的和内容‌。
  2. ‌避免不必要的提交‌：在提交代码前，仔细检查代码，确保不提交不必要的修改或无用的文件。不必要的提交可能会使代码库变得混乱，不利于团队协作和代码维护‌。
  3. ‌遵循分支策略‌：使用分支时，需要遵循分支策略，确保代码库的稳定性和一致性。分支是Gitopen in new window的核心功能之一，允许开发人员在代码库中创建多个版本并在这些版本之间切换‌。
  4. ‌保持代码库干净‌：Git支持撤销和回滚操作，但这些操作会使代码库变得混乱和难以维护。因此，需要保持代码库的干净，只包含高质量的代码和必要的文件‌。

‌具体的Git提交规范包括以下几个方面‌：

  1. ‌提交频率‌：尽量保持提交频率较小，每个提交应包含一个逻辑上的更改或修复。这有助于追踪代码变更的历史和提高代码审查的效率‌。
  2. ‌提交信息格式‌：推荐使用Angular提交说明规范open in new window，包括类型和描述。例如，feat: 新增特性、fix: 修复Bug、docs: 文档变更等。这种格式化有助于快速识别提交的类型和内容‌。
  3. ‌代码质量‌：提交的代码应具有高质量，避免Bug和问题。可以通过代码测试open in new window和代码审查open in new window来确保代码质量和可读性‌。

通过遵循这些规范和注意事项，可以有效地提高代码库的维护性和团队协作的效率。

10. git分支策略

Git 分支策略是团队在使用 Git 进行版本控制时，为了高效管理代码变更、协作开发以及发布流程而采用的一套规则。不同的项目和团队可能会根据自身的需求选择或定制适合自己的分支策略。

以下是几种常见的 Git 分支策略：

  1. GitFlow

    • Master 分支：用来存放正式发布的版本。
    • Develop 分支：作为集成所有新功能的分支，它包含了即将发布的下一个版本的所有更改。
    • Feature 分支：基于 Develop 分支创建，用于开发新的功能。完成后合并回 Develop 分支。
    • Release 分支：当准备发布新版本时，从 Develop 分支创建 Release 分支。在此分支上进行最终测试和修复 bug，之后合并到 Master 和 Develop 分支。
    • Hotfix 分支：当需要紧急修复生产环境中的问题时，从 Master 分支创建 Hotfix 分支。修复完成后，合并回 Master 和 Develop 分支。

  2. GitHub Flow

    • Main (或 Master) 分支：这是部署到生产的分支。
    • Feature 分支：为每个新功能或改进创建一个 Feature 分支。一旦完成并经过审查后，这些分支会被合并回 Main 分支。
    • 通常不区分 Release 或 Hotfix 分支，所有改动都通过 Pull Request 的形式合并到 Main 分支，然后直接部署到生产环境。

  3. GitLab Flow

    • 类似于 GitHub Flow，但更强调环境分支（如 Production, Staging）的概念。
    • 可以有多个长期存在的环境分支来代表不同阶段的部署环境。
    • 每个环境分支都可以有自己的 Feature 分支，并且可以有不同的合并策略。

  4. Trunk-Based Development

    • 所有开发者直接向单一主干分支（通常是 Main 或 Master）提交小的、频繁的更新。
    • 避免了长时间运行的特性分支，鼓励快速反馈和持续集成。
    • 适用于高度自动化测试和持续部署的环境。

每种策略都有其适用场景和优缺点。例如，GitFlow 对于大型项目和有严格版本控制要求的团队可能更适合，因为它提供了清晰的分支结构和流程；而 GitHub Flow 则更加简洁，适合快速迭代的小型项目或者敏捷开发团队。

选择合适的分支策略应该考虑团队规模、项目的复杂度、发布频率以及是否需要支持多版本同时开发等因素。最重要的是确保整个团队对于所选策略的理解一致，并且能够有效地执行。

11. 如何使用git管理项目

使用 Git 来管理项目是一个很好的选择，因为它提供了强大的版本控制功能，可以帮助团队成员更好地协作和追踪代码的变化。下面是使用 Git 管理项目的几个基本步骤：

1. 安装 Git

首先确保你的计算机上已经安装了 Git。可以通过访问 Git 官方网站open in new window 下载并按照说明进行安装。

2. 创建仓库

有两种方式来创建一个新的 Git 仓库：

  • 从现有目录初始化：如果你已经在本地有一个项目文件夹，可以在该目录下打开终端（或命令提示符），运行 git init 命令来将这个文件夹变成一个 Git 仓库。
  • 克隆远程仓库：如果想开始于一个已存在的远程仓库，可以使用 git clone <repository URL> 命令将其复制到本地。

3. 配置用户信息

在首次设置 Git 时，你需要配置用户名和邮箱地址，这样每次提交都会记录这些信息。使用以下命令配置：

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

4. 添加文件到暂存区

当修改了一些文件后，需要先将它们添加到暂存区。可以使用 git add 命令来完成这一步骤：

  • 添加特定文件：git add filename.txt
  • 添加所有更改过的文件：git add .

5. 提交更改

一旦文件被添加到了暂存区，接下来就可以提交这些更改了。使用 git commit -m "Commit message" 来提交，并附上描述性的提交信息。

6. 分支管理

根据所采用的分支策略（如之前提到的 GitFlow, GitHub Flow 等），创建新分支、切换分支、合并分支等操作是非常常见的。常用的命令包括：

  • 查看当前分支：git branch
  • 创建新分支：git branch new-feature
  • 切换分支：git checkout new-feature
  • 创建并立即切换到新分支：git checkout -b new-feature
  • 合并分支：git merge another-branch

7. 推送/拉取更新

与远程仓库同步是保持团队协作的关键。常用命令如下：

  • 将本地更改推送到远程仓库：git push origin main （假设你正在主分支工作）
  • 从远程仓库获取最新更改：git pull origin main

8. 处理冲突

当多人同时对同一文件的不同部分进行修改时，可能会发生合并冲突。解决这类问题通常涉及到手动编辑冲突文件，然后再次添加到暂存区并提交。

9. 使用 .gitignore 文件

.gitignore 文件用于指定哪些文件或目录不应该被纳入版本控制系统中，比如编译产生的临时文件、IDE 设置等。

10. 标签管理

对于重要的版本点，可以打标签以方便日后查找。例如，发布新版本时可以这样做：

  • 创建轻量标签：git tag v1.0
  • 创建带有注释的标签：git tag -a v1.0 -m "Version 1.0"
  • 推送标签至远程仓库：git push origin v1.0

通过遵循上述步骤，你可以有效地使用 Git 来管理和维护你的项目。记得定期备份你的仓库，并利用好 Git 提供的强大功能来提高开发效率。

12. 常见的 Git 分支操作有哪些

  1. 查看所有分支

    • 列出本地分支：git branch
    • 列出远程分支：git branch -r
    • 列出本地和远程的所有分支：git branch -a

  2. 创建新分支

    • 创建一个新分支但不切换到该分支：git branch <branch-name>
    • 创建并立即切换到新分支：git checkout -b <branch-name> 或者使用 git switch -c <branch-name>

  3. 切换分支

    • 切换到已存在的本地分支：git checkout <branch-name> 或者 git switch <branch-name>

  4. 删除分支

    • 删除一个本地分支（如果已经合并）：git branch -d <branch-name>
    • 强制删除一个本地分支（即使未合并）：git branch -D <branch-name>
    • 删除远程分支：git push origin --delete <branch-name>

  5. 重命名分支

    • 重命名当前所在的本地分支：git branch -m <new-branch-name>
    • 重命名非当前所在本地分支：git branch -m <old-branch-name> <new-branch-name>

  6. 合并分支

    • 将指定分支合并到当前分支：git merge <branch-to-merge>
    • 使用快进合并（当历史线性时）：git merge --ff-only <branch-to-merge>
    • 如果有冲突，解决冲突后需要添加解决后的文件到暂存区，并再次提交。

  7. 变基（Rebase）

    • 把当前分支变基到另一个分支上：git rebase <target-branch>
    • 继续变基过程（解决冲突后）：git rebase --continue
    • 跳过当前变基步骤中的某个提交：git rebase --skip
    • 中断变基过程：git rebase --abort

  8. 比较分支

    • 比较两个分支之间的差异：git diff <branch1> <branch2>

  9. 追踪远程分支

    • 设置本地分支跟踪远程分支：git branch --set-upstream-to=origin/<remote-branch> <local-branch>

  10. 推送分支到远程仓库

  • 推送新创建的本地分支到远程仓库：git push -u origin <branch-name>
  • 更新远程分支上的更改：git push origin <branch-name>
  1. 拉取远程分支更新
    • 获取远程仓库中最新的分支列表及数据：git fetch
    • 合并远程分支的更新到当前分支：git pull （等同于 git fetch 加上 git merge）

这些基本操作可以帮助你有效地管理和维护项目中的多个开发流。记住在进行重要的分支操作之前最好先备份你的工作，以防止意外丢失数据。

13. 新功能的开发流程 (GIT)

新功能的开发流程在使用 Git 时通常会遵循一定的分支策略，以确保代码的稳定性和团队协作的高效性。以下是一个基于 Git 的典型新功能开发流程，这个流程可以与 GitFlow 或 GitHub Flow 等分支策略结合使用：

1. 准备阶段

  • 更新主分支：从主分支（通常是 master 或 main）拉取最新代码。

    git checkout master
git pull origin master

  • 创建新功能分支：基于最新的主分支创建一个新的分支用于开发新功能。

    git checkout -b feature/new-feature-name

2. 开发阶段

  • 编写代码：在这个新的功能分支上进行编码工作。

  • 定期提交：当完成一部分功能或达到一个逻辑上的里程碑时，将更改添加到暂存区并提交。

    git add .
git commit -m "Add new feature: [简要描述]"

  • 保持同步：定期将主分支的最新更改合并到你的功能分支中，以避免长期分支导致大量冲突。

    git checkout feature/new-feature-name
git fetch origin
git merge origin/master
# 或者使用 rebase 来保持线性的历史记录
# git rebase origin/master

3. 测试阶段

  • 自测：开发者应首先对新功能进行充分测试。
  • 集成测试：如果项目有持续集成(CI)系统，应该推送代码到远程仓库，并触发自动构建和测试。
    git push origin feature/new-feature-name

4. 代码审查

  • 发起 Pull Request (PR)：将功能分支推送到远程仓库后，在 GitHub、GitLab 或 Bitbucket 等平台上发起一个 PR。
  • 同行评审：其他团队成员审查代码，提供反馈。

5. 合并阶段

  • 解决评论：根据审查反馈修改代码，可能需要多次迭代。
  • 合并代码：一旦所有问题都解决了，且功能经过了彻底的测试，就可以合并到主分支。
    • 如果使用的是 GitHub Flow，则直接通过平台提供的 UI 合并 PR 到 master 或 main。
    • 如果使用的是 GitFlow，可能会先合并到 develop 分支，然后在发布时再从 develop 合并到 master。

6. 清理

  • 删除本地和远程的功能分支：一旦功能被成功合并并且验证无误，可以安全地删除这些临时的功能分支。
    git branch -d feature/new-feature-name
git push origin --delete feature/new-feature-name

7. 部署

  • 根据团队的具体部署流程，可能是手动部署或者通过 CI/CD 自动化部署到生产环境。

整个过程中，重要的是保持良好的沟通，及时更新文档，并遵守团队约定的工作流程。此外，定期备份代码和使用标签来标记重要的版本也是好的实践。

14. git常用的分支？

在使用 Git 进行版本控制时，常见的分支类型有以下几种，每种都有其特定的用途和管理策略。这些分支通常与某种分支策略相关联，比如 GitFlow 或 GitHub Flow。

  1. 主分支（Main 或 Master）

    • 通常是项目的稳定版本分支。
    • 在 GitFlow 中称为 master，而在一些现代实践中可能被称为 main。
    • 该分支上的代码应该是随时可以部署到生产环境的。

  2. 开发分支（Develop）

    • 用于集成新的功能。
    • 在 GitFlow 中称为 develop 分支，它包含了即将发布的下一个版本的所有更改。
    • 开发者从这个分支创建特性分支，并且当特性完成并通过测试后，将它们合并回这里。

  3. 特性分支（Feature）

    • 用于开发新的功能或改进。
    • 通常基于 develop 分支创建，在 GitFlow 中是这样的。
    • 完成后合并回 develop 分支（有时需要通过 Pull Request 的形式）。

  4. 发布分支（Release）

    • 为准备发布新版本而创建。
    • 通常从 develop 分支分出，进行最后的测试、修复bug以及版本号修改等。
    • 在 GitFlow 中，一旦发布完成，发布分支会被合并回 master 和 develop 分支。

  5. 修复分支（Hotfix）

    • 用于快速修复生产环境中出现的问题。
    • 通常直接从 master 分支创建，修复完成后立即合并回 master 和 develop 分支，以确保问题得到及时解决。

  6. 临时分支

    • 可能包括一些短期存在的分支，如实验性的改动或者小的修复。
    • 这些分支往往会在任务完成后被删除。

  7. 长期支持分支（LTS）

    • 对于需要长期维护的旧版本，可能会创建专门的支持分支。
    • 例如，对于一个已经发布了多个版本的软件，可能会有一个 LTS 分支来支持那些不希望升级到最新版本的用户。

  8. 个人分支

    • 某些开发者可能会根据自己的喜好创建个人分支来进行探索性的工作或学习目的。
    • 这些分支通常不会被合并到主分支中。

每个团队可以根据自身的实际情况选择合适的分支策略。重要的是要保持一致性，确保所有成员都理解并遵循所选的流程。这有助于提高团队效率，减少错误，同时保证代码库的质量。

15. git 代码上线流程？

Git 代码上线流程通常包括多个步骤，以确保新代码的质量和系统的稳定性。以下是一个典型的 Git 代码上线流程，它结合了版本控制、代码审查、自动化测试以及部署等环节。这个流程可以适用于多种开发模式，比如 GitFlow 或 GitHub Flow。

1. 准备阶段

  • 更新主分支：从远程仓库拉取最新的 master 或 main 分支代码。
    git checkout master
git pull origin master

2. 开发阶段

  • 创建特性分支：基于最新的 master 或 develop 分支（取决于你使用的分支策略）创建一个新功能或修复的分支。

    git checkout -b feature/new-feature

  • 编写代码并提交：在特性分支上进行开发，并定期提交更改。

    git add .
git commit -m "Add new feature: [描述]"

  • 保持同步：定期将主分支的最新更改合并到你的特性分支中。

    git fetch origin
git merge origin/master
# 或者使用 rebase 来保持线性的历史记录
# git rebase origin/master

3. 测试阶段

  • 单元测试：运行所有相关的单元测试来验证新功能。
  • 集成测试：如果可能的话，运行集成测试来检查新功能与其他部分的交互情况。
  • 推送代码：将特性分支推送到远程仓库。
    git push origin feature/new-feature

4. 代码审查

  • 发起 Pull Request (PR)：在 GitHub, GitLab, Bitbucket 等平台上发起 PR，请求合并到 develop 或 master。
  • 同行评审：团队成员对 PR 进行评审，提出意见和建议。
  • 解决反馈：根据评审结果修改代码，并重新提交直到通过评审。

5. 合并阶段

  • 合并 PR：一旦 PR 被批准，就将其合并到目标分支（如 develop 或 master）。
    • 在 GitHub 上可以通过 UI 直接合并。
    • 如果是手动合并，则执行：
      git checkout master
git merge --no-ff feature/new-feature
git push origin master

6. 部署前准备

  • 标签管理：为发布版本打上标签。
    git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0
  • 构建与打包：根据项目需求进行构建和打包。

7. 部署阶段

  • 预发布环境部署：先将代码部署到预发布环境进行最后的测试。
  • 生产环境部署：确认一切正常后，部署到生产环境。
    • 手动部署或通过 CI/CD 自动化工具部署。

8. 清理

  • 删除特性分支：成功部署后，删除不再需要的本地和远程特性分支。
    git branch -d feature/new-feature
git push origin --delete feature/new-feature

9. 监控与回滚

  • 监控系统状态：部署完成后密切监控系统性能和日志。
  • 准备回滚计划：如果发现问题，准备好快速回滚到之前的稳定版本。

这个流程可以根据团队的具体情况进行调整。例如，一些团队可能会省略某些步骤，或者采用更复杂的持续交付/持续部署(CD)管道。关键在于确保整个过程是透明的、可追溯的，并且能够快速响应任何可能出现的问题。

16. git 多条提交记录合并一条

在 Git 中，你可以通过 rebase 或 squash 将多条提交记录合并为一条。以下是两种常见的方法：

方法一：使用 git rebase 交互模式

  1. 启动交互式 rebase： 假设你想合并最近的 3 条提交记录，可以运行：

    git rebase -i HEAD~3

    这里的 HEAD~3 表示从当前提交往前数的 3 条记录。

  2. 选择要合并的提交： 编辑器会打开，显示类似以下内容：

    pick commit1
pick commit2
pick commit3

    将第 2 和第 3 行的 pick 改为 squash（或简写 s）：

    pick commit1
squash commit2
squash commit3

    保存并关闭编辑器。

  3. 编辑提交信息： Git 会打开一个新的编辑器，让你编辑合并后的提交信息。你可以保留或修改这些信息，保存并关闭编辑器。

  4. 完成 rebase： Git 会将这 3 条提交记录合并为一条。

方法二：使用 git merge --squash

  1. 创建一个新分支（可选）： 如果你想保留原始提交记录，可以先创建一个新分支：

    git checkout -b new-branch

  2. 合并提交： 运行以下命令将多条提交记录合并为一条：

    git merge --squash feature-branch

    这里的 feature-branch 是你想合并的分支。

  3. 提交合并结果： 合并后，Git 会将所有更改暂存，但不会自动提交。你需要手动提交：

    git commit -m "Squashed commit message"
注意事项
  • 备份：在操作前，建议备份当前分支或创建一个新分支，以防操作失误。
  • 冲突：在 rebase 或合并过程中可能会遇到冲突，需要手动解决。

通过以上方法，你可以轻松将多条提交记录合并为一条。

Last Updated:
Contributors: 乙浒