企业级版本管理工具（1）----Git

暂存区（Staging Area）：也称为索引，是版本库中一个非常重要的部分。在你提交更改之前，你可以将它们添加到暂存区。这允许你对即将进行的提交进行精细控制，只提交你想要的部分。
HEAD：在Git中，HEAD是一个特殊的指针，它通常指向你当前所在分支的最新提交。这表示HEAD是你工作副本的历史中的当前状态。
分支和标签：Git的分支和标签是版本库中的引用，它们指向特定的提交。分支通常用于开发、特性添加和bug修复，而标签用于标记发布版本等特定提交。

使用git add将文件添加到暂存区：

使用git commit -m “消息” 将修改提交：

使用git log打印出提交日志：

使用git log --pretty=oneline打印出好看的提交日志：

3.版本回退

1.git reset

git reset是 Git 版本控制系统中一个用于重置当前分支的头部（HEAD）到指定状态的操作。这个命令可以用来撤销之前的提交、撤销暂存区的更改，或者将工作区的文件恢复到之前的版本。

git reset [--soft | --mixed | --hard] [commit]

--soft：只是将 HEAD 指向指定的提交，不会改变暂存区和工作目录的内容。这意味着你的所有更改仍然在暂存区中，你可以重新提交它们。
--mixed（默认选项，可以省略）：将 HEAD 指向指定的提交，并且更新暂存区，使其与指定的提交一致，但是工作目录保持不变。这意味着你的更改仍然在工作目录中，但是不在暂存区中。
--hard：将 HEAD 指向指定的提交，并且更新暂存区和工作目录，使其与指定的提交完全一致。这是一个危险的操作，因为它会丢弃所有未提交的更改。

工作区	暂存区	版本库	回退
git world	git world	git world	git reset
git world	git world	git	--soft
git world	git	git	--mixed 默认选项
git	git	git	--hard 慎用

2.git reflog

git reflog是一个 Git 命令，用于显示 Git 参考日志（reflog），这是一个记录了所有在本地仓库中对分支尖端和HEAD所做的更新的日志。这个命令非常有用，尤其是在您需要恢复丢失的提交或者需要查看最近的操作历史时。

3.撤销修改

git diff可以看到最新的修改：

工作区	暂存区	版本库	解决方式
xxx code			1.手动撤销 2.git checkout -- [filename]
xxx code	xxx code		git reset
xxx code	xxx code	xxx code	前提条件：commit之后没有push

git checkout -- [filename]可以撤销工作区的修改

4.删除文件

git rm 文件可以删除工作区和暂存区的文件：

5.git分支管理

git branch(-r 列出远程分支 -a 列出全部分支)列出当前本地存在的分支：

HEAD可以指向其他分支，被指向的分支就是当前正在工作的分支

git branch 名字可以创建一个新分支：

git checkout 名字切换当前分支：

git merge 分支名将分支合并到当前分支：

git branch -d 分支名删除该分支：

1.合并冲突

多分支同时对文件做出不同的修改再进行合并时会发生合并冲突，需要手动解决冲突并重新提交。

git log --graph --abbrev-commit可以显示出提交图示：

2.合并模式

在Git中，有几种可供选择的合并模式：

Fast-Forward合并模式：当要合并的分支是当前分支的直接上游分支，并且在当前分支上没有新的提交时，Git会使用Fast-Forward合并模式。此时直接将当前分支指针指向上游分支的最新提交，合并完成。
3-way合并模式：当要合并的分支不是当前分支的直接上游分支，或者在当前分支上存在新的提交时，Git会使用3-way合并模式。此模式下，Git会找到当前分支、要合并的分支和它们的共同祖先之间的差异，并生成一个新的合并提交。
合并冲突：当Git无法自动完成合并时，会发生合并冲突。这通常是由于两个分支在同一个文件的同一行做了不同的修改，或者在同一个文件的同一位置创建了不同的文件等。在发生合并冲突时，Git会停下来，提示用户手动解决冲突。用户需要在冲突标记之间编辑文件，解决冲突后再进行提交。

3.合并策略

在Git中，有几种常见的分支策略可以使用，以下是其中几种：

主分支策略：主分支通常是用来存放稳定的、发布的代码。在主分支上进行的修改应该是经过严格测试和审核的，保证代码的质量和稳定性。常见的主分支包括master、main等。
开发分支策略：为了避免直接在主分支上进行开发，通常会从主分支拉取一个用于开发的分支。这个分支可以命名为dev、develop等。在开发分支上进行的修改可以进行测试和调试，并与其他开发者协同工作。当开发工作完成后，将开发分支合并回主分支。
功能分支策略：为了同时进行多个功能的开发，可以使用功能分支策略。每个功能都在独立的分支上开发，例如feature/add-user、feature/login等。通过这种方式，不同功能的开发可以并行进行，并且每个功能都可以单独测试和审查。当功能开发完成时，将功能分支合并回开发分支或主分支。
发布分支策略：当代码达到发布状态时，可以创建一个发布分支，例如release/v1.0。在发布分支上进行最后的测试和准备工作，例如修复bug、更新版本号等。在准备好发布时，将发布分支合并回主分支，并打上对应的标签。
热修复分支策略：当在发布分支上发现紧急的bug时，可以创建一个临时的热修复分支，例如hotfix/bug-fix。在热修复分支上进行bug修复，并将修复的内容合并回主分支和开发分支。

4.bug分支

独立的bug分支是一种用于修复代码中的bug的分支策略。当在开发过程中发现bug时，可以创建一个bug分支来专门处理bug修复，而不会影响到正在进行的开发工作。

以下是一个典型的bug分支策略：

在bug分支上修复bug：当发现一个bug时，从适当的开发分支（如dev）创建一个新的bug分支。可以使用命名约定，如bugfix/issue-number或hotfix/issue-number，其中issue-number是相关问题的编号。
修复bug：在bug分支上进行必要的代码修改和调试，以修复bug。确保只修改与修复bug相关的代码，并且不会引入新的问题。
进行测试：在修复bug之后，进行相应的测试，确保修复不会引入新的问题，并且bug已经被成功解决。
合并回开发分支：一旦bug修复完毕并通过测试，将bug分支合并回原来的开发分支（如dev），确保所有的修复都包含在下一个版本的开发中。
合并到主分支：如果bug修复也需要包含在当前或下一个发布版本中，可以将修复的bug分支合并回主分支（如master），然后进行发布准备工作。

5.git branch -D 分支强制删除分支：

6.git push origin 远程分支:本地分支推送到远程仓库：

7.git pull origin 远程分支:本地分支从远程仓库拉取到本地：

8..gitignore文件可以在提交时忽略某些文件：

配置：*名字.后缀

6.操作标签

1.git config --global alias.st 命令名可以给命令起别名：

2.git tag 标签名（commit码）（-d选项为删除标签）为最新一次提交打标签：

3.git show 标签名查看详细信息：

4.git push origin 标签名（:标签名为删除）将标签推送到远程：

7.变基

在Git中，变基（rebase）是一种用于整理和修改提交历史的操作。它允许将一系列提交记录应用到另一个提交上，创建一条线性的提交历史。

变基操作的基本语法是 git rebase <目标分支>，它会将当前分支的提交记录重新应用到目标分支上。以下是一些常见的变基操作：

变基到主分支：当想要将当前分支的提交记录合并到主分支时，可以使用git rebase master。这个操作将把当前分支的提交记录重新应用到主分支上，并将主分支的更新合并到当前分支。
变基解决冲突：在变基过程中，如果发生冲突，Git会暂停变基操作，让你解决冲突后继续。解决冲突的方法与解决合并冲突类似，使用git add命令将冲突文件标记为已解决，然后继续git rebase --continue。
变基合并提交：在变基过程中，可以选择合并多个提交，并创建一个更简洁的提交历史。使用git rebase -i命令可以打开交互式的变基编辑器，允许你合并、编辑和删除提交。