Git常用命令

从工作的角度来看，掌握Git是提高团队协作效率、代码质量和个人职业发展的重要一环。在现代软件开发中，很难想象没有一个强大的版本控制系统是如何维护和管理代码的。

提交原理

Git 提交原理涉及到**工作目录、暂存区（Index）和版本库（Repository）**三个主要区域。以下是 Git 提交的基本原理：

工作目录（Working Directory）：

工作目录是你本地存储 Git 仓库的地方，包含你的项目文件。
你在工作目录中修改文件，这些修改被视为工作目录的“未跟踪”状态。
暂存区（Index）：

暂存区是一个中间区域，用于存放你已经修改但还未提交的更改。
当你在工作目录中修改了文件后，你需要将这些修改添加到暂存区，这就是使用 git add 命令的时候发生的事情。
暂存区允许你选择性地将修改添加到下一次提交中，使得你可以将相关的修改分开提交，而不是一次性提交所有更改。
版本库（Repository）：

版本库是 Git 存储历史记录的地方，包含了项目的完整历史。
当你使用 git commit 命令时，暂存区的内容被提交到版本库中，形成一个新的提交（commit）。
提交包含了你所做的修改的快照、作者、提交时间等信息。
基本的 Git 提交流程如下：

修改文件： 在工作目录中修改项目文件。

将修改添加到暂存区： 使用 git add 命令将你想要提交的修改添加到暂存区。

提交到版本库： 使用 git commit 命令将暂存区的内容提交到版本库中，形成一个新的提交。

这个过程可以多次重复，每次修改后都执行 git add 将修改添加到暂存区，然后使用 git commit 提交到版本库。这种分阶段提交的方式使得版本控制更加灵活，允许你对每个提交进行有意义的分组。

基本代码提交

git add . //表示提交所有更改项以及未被跟踪的文件到暂存区
或者 git add xiaozhaodebug.txt  //表示只提交xiaozhaodebug.txt到暂存区
git commit -m "初版"   //提交到版本库中。
git pull origin develop   //从远程仓库origin的develop分支拉取最新信息，起到同步作用。这里可能会出现冲突，后面介绍
git push origin develop //把你前面新增特性功能 上传远程仓库，其他伙伴重新拉去代码，就能获取你的代码了。

修改远程仓库commit和本地仓库的commit

1. 使用交互式 rebase： 打开命令行或终端，导航到您的项目目录，然后运行以下命令：

   git rebase -i HEAD~n
   

   其中 n 是您想要修改的提交数量。

2. 选择编辑： 在弹出的文本编辑器中，将您想要修改的提交前的 pick 修改为 edit 或简写为 e。

3. 修改提交： 进入修改状态后，您可以进行修改，包括添加、修改或删除文件。

4. 添加修改后的文件： 使用以下命令将修改后的文件添加到暂存区：

   git add 文件名
   
   

5. 提交更改： 提交修改后的文件：

   git commit --amend
   
   

   这会将更改添加到之前的提交中。

6. 继续 rebase： 完成修改后，继续 rebase 操作：

   git rebase --continue
   
   

修改远程仓库的提交：

如果您已经推送到远程仓库，建议不要修改提交，以免引起同步问题。如果您确实需要修改，并且确定您是唯一修改者，可以使用 --force 选项推送：

git push --force origin 分支名

请注意，使用 --force 选项会覆盖远程仓库的历史，可能会影响其他人的工作。确保在执行此操作之前与团队协商，以避免潜在的冲突。

在任何情况下，请谨慎使用这些命令，确保你了解其潜在影响。

分支合并

要将一个分支合并到另一个分支，您可以使用以下命令：

1. 切换到目标分支： 首先，确保您在想要将变更合并到的目标分支上。使用以下命令切换到目标分支，比如将分支B合并到分支A：

   git checkout 分支A
   

2. 执行合并操作： 使用 git merge 命令将其他分支合并到当前分支。在这里，我们将分支B合并到分支A：

   git merge 分支B
   

   如果您希望在合并时保持一个简洁的提交历史，您也可以使用 --no-ff 选项：

   git merge --no-ff 分支B
   
   

   这将创建一个新的合并提交，即使是快进（Fast-forward）合并。

3. 解决合并冲突（如果有）： 如果Git无法自动合并更改，它将提示合并冲突。您需要手动解决这些冲突，然后继续合并。

4. 提交合并结果： 如果没有冲突或冲突已解决，提交合并的结果：

   git commit -m "合并分支B到分支A"
   

   如果您使用了 --no-ff 选项，Git将提示您输入合并的提交信息。
   这样，就成功将一个分支合并到另一个分支了。确保在合并前，已经完成并提交了在目标分支上的任何更改。如果在合并之前想要预览变更，可以使用 git diff 分支A..分支B 来查看分支B相对于分支A的差异。

保留当前修改，不commit，切换分支

如果您有未提交的更改，想要保留这些修改而不进行提交，然后切换到另一个分支，可以使用以下步骤：
sh

1. 查看未提交的更改：

git status

确保您知道有哪些未提交的更改。

2. 保留当前修改：

您可以选择将当前修改进行暂存，这样您就可以在切换分支后还原这些修改。

git stash

这会将当前未提交的更改暂存起来，让您的工作目录变为干净状态。

3. 切换分支：

git checkout 目标分支

将 “目标分支” 替换为您想要切换到的分支。

4. 还原暂存的修改：

一旦切换到目标分支后，您可以还原之前暂存的修改：

git stash apply

或者，如果您想要在应用修改的同时将其从 stash 中移除，可以使用：

git stash pop

这将重新应用之前暂存的修改到当前分支。

通过这个过程，可以保留当前未提交的修改，切换到其他分支进行工作，然后再回到原来的分支并应用之前暂存的修改。请注意，如果切换分支时有未提交的修改，Git可能会拒绝切换，因此使用 stash 可以方便地处理这种情况。

更新submodule 子模块

1. 在主项目中更新子模块：

   git submodule update --recursive --remote
   
   

   这会将子模块更新为其最新提交。使用 --recursive 选项确保所有的子模块都被更新。

2. 提交主项目中子模块的新版本：

   
   git add 子模块路径
   git commit -m "更新子模块"
   git push origin 分支名
   
   

   确保您在主项目中提交了子模块的最新版本。

这两个步骤的目标是在主项目中更新子模块并将主项目中子模块的新版本提交。这样其他人克隆或拉取主项目时，可以使用这个最新的子模块版本。

请注意，当您拉取或克隆主项目时，确保使用 --recursive 选项以便初始化并更新所有子模块：

bashCopy code
git clone --recursive <主项目URL>

或者，如果已经克隆了主项目，可以使用以下命令初始化和更新子模块：

git submodule update --init --recursive

这将确保克隆或拉取的主项目包含所有最新的子模块。

要查看仓库中有多少个子模块，可以使用以下命令：

git submodule status

这会列出所有子模块的信息，包括每个子模块的状态、提交ID、分支信息等。每个子模块的条目看起来像这样：

+dc7f1d09...212e21d2 子模块路径（branch '分支名'）

其中，dc7f1d09...212e21d2 是子模块的提交ID，子模块路径 是子模块在主项目中的路径，分支名 是子模块所在的分支。

如果您只关心子模块的数量，您可以使用以下命令：

git submodule status | wc -l

这会输出子模块的数量。

cherry-pick

如果想将另一个分支上的某个提交（commit）合并到当前分支上，可以使用 git cherry-pick 命令。以下是基本步骤：

1. 切换到目标分支：

首先，确保您在要合并提交的目标分支上：

git checkout 目标分支

2. 执行 cherry-pick：

运行 git cherry-pick 命令，指定要合并的提交的哈希值：

git cherry-pick 提交的哈希值

将 “提交的哈希值” 替换为您想要合并的提交的实际哈希值。

3. 处理冲突（如果有）：

如果在 cherry-pick 过程中发生冲突，您需要手动解决冲突并完成合并。Git 会提示您处理冲突的步骤。

4. 提交合并结果：

一旦您解决了所有冲突，使用以下命令提交合并结果：

git commit

示例：

# 切换到目标分支
git checkout 目标分支

# 执行 cherry-pick
git cherry-pick 提交的哈希值

# 处理冲突（如果有）

# 提交合并结果
git commit

这样，您就将另一个分支上的特定提交合并到了当前分支上。请注意，这种方法会在当前分支上创建一个新的提交，而不是将整个分支合并过来。

git fetch

在使用Git时，git fetch 和 git pull 都用于从远程仓库获取最新的代码，但它们之间有一些区别。以下是一些情况下你可能会选择使用 git fetch 而不是 git pull：

1. 预览远程变更：
   • 如果你只是想要查看远程仓库的最新状态，而不想将这些变更立即合并到你的本地分支，使用 git fetch 是一个更安全的选择。它只会下载远程信息，你可以随时决定是否要进行合并。
2. 避免自动合并：
   • git pull 会自动将远程分支的变更合并到你的本地分支，这可能导致冲突。如果你想要手动控制合并的时机，可以使用 git fetch 避免自动合并。
3. 查看远程分支的状态：
   • git fetch 会将远程分支的最新状态保存在 origin/branch 中，而不会修改本地分支。这允许你查看远程分支的状态，然后决定是否需要将变更合并到本地分支。
4. 避免工作目录的变更：
   • git pull 会直接修改你的工作目录，将远程变更合并到本地分支。如果你不想立即应用这些变更，而是想要在合适的时机手动合并，使用 git fetch 可以避免直接修改工作目录。
5. 多人协作场景：
   • 在多人协作的情况下，使用 git fetch 允许你先了解其他团队成员的工作情况，然后根据需要进行合并。这有助于避免意外的冲突和合并问题。

以上是工作中常用git命令，命令那么多难免会有些记不住，这里分享vscode一些插件，替代手敲操作，有兴趣可以了解下

分支模型

在Git中，分支模型是指在软件开发中使用Git进行版本控制时，如何管理和组织代码的分支结构。Git的分支模型基于分布式版本控制系统的特性，允许多个开发者同时工作，并且支持并行开发。以下是常见的Git分支模型：

主分支（Master/Main）：

主分支是代码仓库的主要分支，代表了稳定的、可发布的版本。
通常，生产环境中的代码就是主分支的内容。
开发分支（Develop）：

开发分支是主要的集成分支，包含了各种功能和修复的代码。
所有开发者的工作都基于这个分支展开，确保每个开发者的修改都能够整合到同一个分支中。
特性分支（Feature）：

特性分支用于开发新功能。每个特性都在一个单独的分支上进行开发，这样可以隔离不同功能的修改。
特性开发完成后，分支合并回开发分支。
发布分支（Release）：

发布分支用于准备发布的版本。在这个分支上进行最终的测试、修复bug和准备发布的元数据。
完成后，发布分支合并回主分支和开发分支。
修复分支（Hotfix）：

修复分支用于紧急修复生产环境中的问题，与发布分支类似，但是是针对已发布版本的修复。修复完成后，分支合并回主分支和开发分支。
Git分支模型的优势在于它提供了清晰的结构，使得团队能够同时进行多个任务而不影响彼此的工作。同时，通过合并分支，团队可以将各个功能的修改整合到主分支中，确保代码的稳定性和可维护性。