Git使用【中】

欢迎来到Cefler的博客
博客主页：那个传说中的man的主页
个人专栏：题目解析
推荐文章：题目大解析3

---

分支管理

分支概念

在 Git 中，分支（branch）是用于将版本库中开发的不同版本分开管理的一种方式。如果你想要开发一个新的功能或修复一个 bug，那么可以基于当前分支创建一个新的分支，然后在这个分支上进行修改和调试，当完成任务后，将这个分支合并回主分支中去。这种分支管理方式可以非常方便地实现多人协作开发、持续集成等。

以下是 Git 分支管理中常用的一些概念：

1. 主分支（master）：主分支是 Git 默认创建的分支。它通常用于存储稳定版本的代码。所有提交历史都会出现在主分支上。

2. 开发分支（develop）：开发分支是用于存放最新的开发版本的分支。它基于主分支创建，开发人员可以在这个分支上进行修改和添加新功能。

3. 特性分支（feature branch）：特性分支是用于实现单一特性或功能的分支。它们通常基于开发分支创建，并在完成特性开发后被合并回开发分支。

4. 发布分支（release branch）：发布分支是用于准备发布新版本的分支。它们基于开发分支创建，在测试阶段被使用，并在通过测试后被合并回主分支和开发分支。

5. 热修复分支（hotfix branch）：热修复分支是用于紧急修复 bug 的分支。它们基于主分支创建，修复后被合并回主分支和开发分支。

Git 分支管理的主要优点是可以帮助开发人员更好地组织和管理版本库中的代码，并不会对其他分支上的代码产生影响。同时，Git 的分支操作相对简单，使用方便。

---

在版本回退⾥，我们已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀
个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所
以，HEAD 指向的就是当前分⽀

每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽
HEAD只要⼀直指向master分⽀即可指向当前分⽀。

而分支就是在主分支的基础上再开辟一个新的分支，进行新的操作，最后任务完成，进行合并分支。

git branch（查看/删除分支）

当使用 Git 进行版本控制时，git branch 命令是非常有用的。git branch 用于查看、创建和删除分支。

以下是 git branch 命令主要用途的概述：

1. 查看分支：运行 git branch 命令可以列出当前版本库中存在的所有分支，并标记出当前所在的分支。命令输出中以星号 (*) 标记的分支表示当前所在的分支。

2. 创建分支：使用 git branch 命令可以创建一个名为 的新分支。新分支将基于当前所在分支创建，并且初始时与当前分支指向同一个提交。

3. 切换分支：通过 git checkout 命令可以切换到 分支。这样你就可以在不同的分支之间切换工作，进行不同的开发任务。

4. 删除分支：使用 git branch -d 命令可以删除名为 的分支。删除分支前，你需要确保当前没有未合并的修改。请注意，如果分支上有未合并的修改，Git 会拒绝删除该分支。如果你确定要强制删除分支，可以使用 -D 参数代替 -d 参数。

当前分支下直接删除当前分支。因为如果你删除当前分支，那么就没有有效的分支指向你的当前工作进度，这可能会丢失一些未提交的修改。如果你想删除当前分支，你需要先切换到其他分支，然后再执行删除操作

5. 重命名分支：运行 git branch -m 修改当前所在的分支的名称。

6. 查看远程分支：通过 git branch -r 命令可以查看远程仓库中的分支列表。

git checkout(切换分支)

git checkout 命令在 Git 分支管理中起着关键作用。它主要用于切换分支、创建分支和撤销修改。下面是 git checkout 在分支管理中的几个常见用途：

1. 切换分支：通过 git checkout 可以切换到指定名称的分支。例如，git checkout develop 将工作目录切换到名为 “develop” 的分支上。切换分支后，你可以在新分支上继续进行开发工作。

2. 创建分支并切换：在 git checkout 命令中加上 -b 参数，可以在切换分支的同时创建一个新分支。例如，git checkout -b feature-branch 将创建一个名为 “feature-branch” 的新分支，并将工作目录切换到该分支上。

3. 撤销修改：使用 git checkout -- 可以撤销对指定文件的修改。这个命令将会将文件恢复到最近一次提交的状态。如果不指定文件名，则会撤销所有未提交的修改。

4. 切换到特定的提交：可以使用 git checkout 切换到指定的提交。这在需要查看历史提交的文件内容或进行旧版本的修复时非常有用。

5. 切换到标签：使用 git checkout 可以切换到指定的标签。标签是版本库中的一个具名提交，可以用于标记重要的里程碑或发布版本。

git merge(合并分支)

git merge 命令在 Git 分支管理中用于合并分支。它的作用是将一个分支的修改合并到另一个分支，使得两个分支的修改都包含在一起。下面是 git merge 在分支管理中的几个常见用途：

下面是两个使用 git merge 命令的例子：

1. 合并特性分支

假设你在开发一个新的功能，创建了一个名为 feature-branch 的特性分支。在完成特性开发后，需要将特性分支的修改合并到主分支上。

首先，切换到主分支：

git checkout master

然后，使用 git merge 命令将特性分支合并到主分支上：

git merge feature-branch

如果合并中存在冲突，Git 会提示冲突文件和行号，需要手动解决冲突。完成冲突解决后，再次提交合并结果即可。

2. 合并远程分支

假设你正在与其他开发者协作，需要将远程分支合并到本地分支上。假设远程分支名为 remote-branch，本地分支名为 local-branch。

首先，从远程分支拉取最新代码：

git fetch origin remote-branch

然后，切换到本地分支：

git checkout local-branch

最后，使用 git merge 命令将远程分支合并到本地分支上：

git merge origin/remote-branch

这样就可以将远程分支的修改合并到本地分支上了。如果合并中存在冲突，需要手动解决冲突。

合并冲突

当你在 Git 中合并两个分支时，可能会遇到合并冲突。合并冲突发生在两个分支都对同一部分文件或代码进行了修改，并且 Git 无法自动决定应该使用哪个版本的修改。

以下是处理合并冲突的一般步骤：

1. 合并分支：执行合并命令，比如 git merge，将一个分支的修改合并到当前分支上。

   git merge branch-name
   

   其中 branch-name 是要合并的分支的名称。

2. 发生冲突：如果发生了合并冲突，Git 会在命令行输出提示信息，告知哪些文件存在冲突。

   Auto-merging file.txt
   CONFLICT (content): Merge conflict in file.txt
   

3. 解决冲突：打开冲突的文件，你会看到类似下面的标记：

   <<<<<<< HEAD
   // 当前分支的修改
   =======
   // 要合并的分支的修改
   >>>>>>> branch-name
   

   这表示冲突的起点、当前分支的修改和要合并的分支的修改。根据你的需求，手动编辑代码，选择保留哪些修改或者做进一步的修改。

4. 解决完所有冲突后，保存文件，并使用 git add 命令将解决后的文件标记为已解决。

   git add file.txt
   

5. 完成合并：一旦所有冲突都解决并且文件已标记为已解决，使用 git commit 命令提交合并结果(提交很重要！！)。

   git commit
   

   Git 会自动生成一个合并提交，包含解决冲突的说明和相关的提交哈希。

处理合并冲突需要注意以下几点：

• 仔细审查冲突的代码，确保修改不会导致功能错误或代码问题。
• 可以使用工具或编辑器的冲突解决功能来辅助解决冲突。
• 在解决冲突之前，请备份重要的文件或项目，以防止错误的修改对你的工作造成不可逆的影响。

处理合并冲突可能需要一定的经验和技巧，但通过谨慎和仔细处理，你可以成功解决冲突并完成合并操作。

分支管理策略

Fast-forward 模式和非 Fast-forward 模式

在 Git 中，合并分支时存在两种模式：Fast-forward 模式和非 Fast-forward 模式。

1. Fast-forward 模式：
   • Fast-forward 模式是默认的合并模式。
   • 在 Fast-forward 模式下，如果要合并的分支是当前分支的直接上游分支，Git 会简单地将当前分支指向最新提交的位置，形成一个线性的提交历史。
   • Fast-forward 模式没有额外的合并提交，因此合并后的提交历史会比较简洁。

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提
交到底是 merge 进来的还是正常提交的。

2. 非 Fast-forward 模式：
   • 非 Fast-forward 模式用于那些不能进行 Fast-forward 合并的情况，比如要合并的分支和当前分支之间有其他的提交。
   • 在非 Fast-forward 模式下，Git 会创建一个新的合并提交，将两个分支的修改合并在一起，并形成一个新的提交节点。这样可以保留每个分支的所有历史记录。
   • 非 Fast-forward 模式的合并会在提交历史中明确显示合并操作，更加清晰地展示了分支的合并流程。

切换到非 Fast-forward 模式需要使用 --no-ff 参数执行合并命令。例如：

git merge --no-ff branch-name

其中 branch-name 是要合并的分支的名称。通过添加 --no-ff 参数，即可强制使用非 Fast-forward 模式进行合并。

非 Fast-forward 模式的优点包括：

• 保留了每个分支的完整提交历史，更加清晰地追踪分支的演进和合并过程。
• 明确标记了每次合并操作，便于代码审查、问题定位以及跟踪变更来源。
• 具备了更好的可读性和可维护性，可以更方便地回溯和撤销合并操作。

注意，在使用非 Fast-forward 模式合并分支时，会产生一个新的合并提交。这样的提交历史可能会显得稍微复杂一些，但也提供了更详细的信息，特别是在多人协作开发或复杂的项目中会更有用。

git log --graph --abbrev-commit

git log --graph --abbrev-commit 是一个常用的 Git 命令，用于以图形化方式展示提交历史。该命令将显示一个分支图，其中包含了提交节点和它们的连接关系。（abbreviation——缩略词）

执行 git log --graph --abbrev-commit 命令后，你会看到类似下面的输出：

*   commit1 (HEAD -> branch1)
|\
| * commit2
| * commit3
|/
* commit4

这个简单的示例表示有两个分支：branch1 和默认分支（通常是 master）。该输出显示了以下信息：

• 每个提交节点用一个星号 * 表示。
• 每个提交节点的哈希值被缩写为几个字符，使用 --abbrev-commit 参数指定缩写的长度。
• 在本例中，commit1 是当前所在分支 branch1 的最新提交，具有 HEAD -> branch1 标签。
• commit2 和 commit3 是 branch1 分支上的其他提交。
• commit4 是默认分支上的一个提交。

通过 git log --graph --abbrev-commit 命令，你可以更直观地查看提交历史，并了解分支之间的合并情况和提交的连接关系。这对于理解项目的演进和跟踪代码变更非常有帮助。

值得注意的是，--graph 参数用于显示提交历史的图形，--abbrev-commit 参数用于缩写提交哈希值。你可以根据需要修改这些参数或者使用其他命令选项来获取更多定制化的输出。

分支策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活。

当我们想要开发一个新的功能，我们只能创建新的分支进行开发，当经过多次的测验与完善，最终将稳定的代码合并到主分支上，此时主分支才是稳定的，可供用户使用的。

bug分支

Git 中的 “bug 分支” 并不是一个特定的分支类型，而是一种通用的术语，用于描述解决项目中出现的 bug 或问题所创建的分支。

当在项目中发现 bug 时，为了修复它，通常会采取以下步骤：

1. 创建分支：首先，你可以基于当前的主分支（例如 master 分支）创建一个新的分支来处理 bug。可以为这个分支起一个有意义的名称，如 bug-fix、fix/bug-name 等。这个分支将成为你解决 bug 的工作区。

   git checkout -b bug-fix
   

2. 解决 bug：在新创建的 bug 分支上，你可以进行代码修改、调试或其他必要的操作来修复 bug。你可以使用各种开发工具和调试技巧来帮助定位和解决问题。

3. 提交修改：当 bug 修复完成后，将修改提交到 bug 分支。

   git add .
   git commit -m "Fix bug: bug description"
   

4. 测试和验证：确保在 bug 分支上的修复能够成功解决问题。你可以运行相关的测试用例、手动测试或者验证其他的途径来确认 bug 是否已经修复。

5. 合并到主分支：当你确定 bug 修复成功后，可以将 bug 分支合并回主分支，以便将修复应用到主代码库中。

   git checkout master
   git merge bug-fix
   

6. 清理分支：一旦 bug 分支的修复已经合并到主分支，可以选择删除该 bug 分支。

   git branch -d bug-fix
   

使用 bug 分支的好处包括：

• 隔离了 bug 修复过程，避免了对主分支的直接修改，从而减少了在修复过程中引入其他问题的风险。
• 允许团队成员并行处理多个 bug，并将每个修复独立地追踪、测试和验证。
• 通过合并 bug 分支，将修复应用到主代码库中，确保了修复被所有用户所使用。

总结来说，通过创建 bug 分支来解决项目中的 bug 是一个良好的开发实践。它提供了一种结构化的方式来处理和跟踪问题，并有效地管理修复过程。

在dev分支上还在开发未提交，但master分支上出现bug了

虽然在master上面会看到dev那边的修改(增添了I am coding…)，但是其实影响不大，因为dev只是在工作区进行修改，也没有add、commit、分支合并，所以版本库中的代码还是没有变化的。

但是如果我们仍然不想在master分支上看到dev那边的修改。
我们可以用到一个新的命令git stash,它可以将工作区上的代码先存储到stash中。

注意：能使用git stash的对象，前提是这个文件是被git追踪的,什么是被追踪呢？就是进行过add操作，commit操作的文件。

那么这说来说去，跟我们修复Bug有什么关系呢？
刚刚我们这个问题的前提是，dev分支上还在开发未提交，但master分支上出现bug了
此时我们在dev分支上咔咔敲代码，这些代码还是在工作区上的，还未提交，我们想让dev的代码情况和master目前一样，但我们又不能删除现在写的代码，所以我们就可以用git stash将目前写的代码先存起来，后面修复完bug后，再取回来。而接下来，我们就可以进行修复bug了。
这一切的大致流程如下：
1.git stash先存储dev分支上在工作区上写的代码
2.git checkout master回到master分支上再创建一个新的分支fix_bug用来修改Bug，在fix_bug分支上修改完后记得add和commit
3.修改完bug后回到master分支，此时一定要记得合并fix_bug分支，此时master才会同步fix_bug上面的修改

4.此时我们在git checkout dev回到dev分支，此时我们就要取回我们之前在dev工作区写的代码了，
我们可以用git stash list查看有哪些存储的代码，然后git stash pop可以拿取回存储的代码

此时代码就已经回来了，而后如果现在工作区的代码已经写完，我们可以在当前分支上进行add、commit了

5.此时回到master分支上，我们可以选择先在master上合并分支dev,但是这里并不推荐这么做，因为可能会出现合并冲突的问题，而如果要手动去改代码可能会出现Bug.
而有个比较好的方案是：
第一步：我们可以采取先在dev分支上合并master，万一出现了合并错误，我们也只要在dev分支上修改代码，而不影响到master分支，等到多次测验稳定后，确认无合并错误和代码错误。
第二步：此时我们再回到master分支，将dev分支进行合并。
操作如下

出现合并冲突了，但没关系，我们直接在dev本地分支上进行解决合并冲突。

这样合并冲突就已经解决了，并且也成功将master合并到dev中了。

而此时我们就可以再回到master分支上将完善的dev分支合并回master分支了。

至此，我们的修复Bug就已经大功告成了
接下里，再归纳一下git stash的用法

git stash

Git stash 是一个非常有用的命令，可以让你暂存当前正在进行的工作，以便在稍后的某个时间点重新应用它。使用 Git stash 命令，你可以将当前的未加入暂存区或提交的变更保存到“临时存储区”（stash）中，然后返回到干净的工作状态，以便在其他任务上继续工作。

下面是使用 Git stash 的一些常见场景和命令示例：

1. 暂存当前修改：运行 git stash save （save可以省略不写）命令，可以将当前工作区中的所有变更保存到 stash 中。

   git stash save "Working on new feature"
   

2. 查看 stash 列表：运行 git stash list 命令，可以列出所有存在的 stash 记录，包括它们的标识符、关联消息和创建时间等信息。

   git stash list
   

3. 应用 stash：运行 git stash apply 命令，可以将最近的 stash 恢复到工作区。如果你有多个 stash 记录，则需要指定 stash 标识符（例如 stash@{2}）。

   git stash apply
   git stash apply stash@{0}
   

4. 删除 stash：运行 git stash drop 命令，可以删除指定的 stash 记录。如果你不指定 stash 标识符，则默认删除最近的 stash 记录。

   git stash drop stash@{1}
   git stash drop
   

5. 恢复并删除 stash：运行 git stash pop 命令，可以将最近的 stash 恢复到工作区并将其从 stash 列表中删除。如果你有多个 stash 记录，则需要指定 stash 标识符。

   git stash pop
   git stash pop stash@{2}
   

使用 Git stash 的优点包括：

• 它允许你在切换分支或处理其他任务之前轻松地暂存当前工作，而无需提交或取消变更。
• 它对于保存一些临时性的代码更改，等待后续开发需要进行调整和修改时非常有用。
• 它可以允许你在进度上进行实验，因为你可以保存未完成的任务，并在稍后恢复。

远程操作

理解分布式版本控制系统

我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者
计算机上。⽽我们的 Git 其实是分布式版本控制系统！什么意思呢？

可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹
了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作
呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需
把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了。

分布式版本控制系统的安全性要⾼很多，因为每个⼈电脑⾥都有完整的版本库，某⼀个⼈的电脑坏掉
了不要紧，随便从其他⼈那⾥复制⼀个就可以了。
在实际使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能
你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开
机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅
是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部丢失，包括git的所有内容）

远程仓库

我们在上述中，已经知道了中央服务器这个概念了。
而我们现实生活中，充当着这一角色的，有我们耳熟能详的github和gittee,前者是国外的网站，后者则是国内的网站。
而接下来，我将主要演示gittee中的一些使用

新建远程仓库

这里介绍一下gitee中reame文件、issue模板文件、pull request模板文件

reame文件、issue模板文件、pull request模板文件

当使用 Git 进行团队协作或开源项目管理时，常用的三个文件是 README 文件、Issue 模板文件和 Pull Request 模板文件。

1. README 文件：
   README 文件通常是一个项目的入口文件，用于向其他开发者和用户介绍项目的概要信息、功能特点、安装指南和使用说明等。它以纯文本格式或使用标记语言（如 Markdown）编写，通常位于项目的根目录下，并提供必要的信息和链接。

   README 文件的内容可以包括但不限于以下内容：

   • 项目名称、介绍和作者信息
   • 安装和使用说明
   • 示例代码或演示
   • API 文档链接
   • 贡献指南和许可证信息
   • 常见问题解答（FAQ）

2. Issue 模板文件：
   Issue 模板文件用于规范化和简化提交 Issue 的流程。它定义了创建 Issue 时需要填写的字段和模板，以便提供更准确的信息。通常，Issue 模板文件以 Markdown 或 YAML 格式编写，存放在项目的 .github/ISSUE_TEMPLATE/ 目录下。

   Issue 模板文件可以包含以下内容：

   • Issue 的类型和标题
   • 描述问题或功能请求的详细信息
   • 复现步骤或相关代码
   • 预期行为和实际结果
   • 环境信息（操作系统、软件版本等）

   使用 Issue 模板文件可以帮助项目维护者和贡献者更好地理解和处理问题，提高沟通效率。

3. Pull Request 模板文件：
   Pull Request 模板文件用于定义创建 Pull Request 时需要填写的字段和模板。它能够引导开发者提供必要的信息，如修改的内容、关联的 Issue 等。通常，Pull Request 模板文件以 Markdown 或 YAML 格式编写，存放在项目的 .github/PULL_REQUEST_TEMPLATE/ 目录下。

   Pull Request 模板文件可以包含以下内容：

   • 修改的概述和目的
   • 关联的 Issue 编号
   • 测试方法和验证步骤
   • 提交的代码变更和影响范围
   • 需要 Review 的人员

   使用 Pull Request 模板文件可以使代码审查过程更加高效，减少开发者和维护者之间的理解偏差，并提供清晰的反馈和讨论。

总的来说
readme文件用来介绍项目的主要信息
issue文件用来提出要解决的问题
pull request 文件就是其它分支的合并提交请求，如果管理员同意了，则可以合并到master中

克隆仓库(git clone)

1.HTTPS协议克隆

我们在gitee中创建好仓库后，可以复制HTTPS协议，然后在本地中用git clone HTTPS协议命令创建一个远程仓库

2.SSH协议克隆

当我们直接复制SSH协议去克隆的时候。

此时会发现不能被创建。
主要原因是我们未在gitee上配置我们的SSH公钥，由于我们没有添加公钥到远端库中，服务器拒绝了我们的 clone 链接。

那么我们如何进行配置公钥呢？步骤如下;
1.创建SSH Key。在用户主目录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有
id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要创建
创建SSH Key需要命令

ssh-keygen -t rsa -C "email.com" 

这里已经有了id_rsa 和 id_rsa.pub 这两个⽂件就不用创建了

之后取个标题，就配置好一个公钥了。

向远程仓库推送（push）

法一;

我们需要先设置全局邮箱和全局用户

git config --global user.email "邮箱"
git config --global user.name "用户名"

有了这个铺垫，我们就可以进行commit、push 操作了

我们用SSH协议创建仓库后出现了这个问题。但我们只要git init初始化仓库一下就可以解决问题

但是初始化之后，我们仍然会出现一些问题

我们这里没有远程仓库origin了，问题官方给出的解决方案如下


此时终于有origin了

推送成功！这⾥由于我们使⽤的是 SSH 协议，是不⽤每⼀次推送都输⼊密码的，⽅便了我们的推送操
作。如果你使⽤的是 HTTPS 协议，有个⿇烦地⽅就是每次推送都必须输⼊⼝令。

git push origin master:master//左边是本地分支，右边是远程分支
意思就是将本地分支推送到远程分支，但如果左右分支相同，右边的分支可以省略不写

总结一下就是：

git push <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>

拉取远程仓库

使用 git pull 命令可以从远程仓库拉取最新的更新到本地仓库。具体操作如下：

1. 确保你当前所在的目录是你的本地仓库目录。

2. 运行以下命令拉取远程仓库的更新：

   git pull  
   

   其中， 是远程仓库的名称，比如 origin； 是要拉取的分支名称。

   例如，如果你要从名为 origin 的远程仓库的 main 分支拉取更新，可以运行：

   git pull origin main
   

3. Git 会尝试将远程仓库的更新合并到当前所在的分支上。如果没有冲突，Git 会自动完成合并操作；如果有冲突，你需要手动解决冲突。

   如果拉取成功且没有冲突，你的本地仓库就会被更新到远程仓库最新的状态。

值得注意的是，如果你在拉取前已经对本地仓库做了修改并且还未提交，Git 可能会报错并拒绝拉取。这时你需要先提交或撤销你的修改，然后再运行 git pull。

另外，如果你只想查看远程仓库的更新而不进行合并，你可以使用 git fetch 命令。它会将远程仓库的更新下载到本地，但不会自动合并。你可以使用 git log 或其他命令查看下载的更新，然后根据需要进行合并操作。

忽略特殊文件(.gitignore)

.gitignore 文件是用来指定在 Git 仓库中需要被忽略的文件或目录。当你在项目中使用 Git 进行版本控制时，有些文件或目录可能不希望被纳入版本控制，例如编译生成的临时文件、日志文件、缓存文件等。通过使用 .gitignore 文件，你可以告诉 Git 忽略这些文件，使它们不会出现在你的版本历史中。

以下是一些关于 .gitignore 文件的重要信息和用法：

1. 文件位置：.gitignore 文件通常放置在项目根目录下。在这个文件中列出的规则将适用于整个仓库及其子目录。

2. 规则格式：每行一个规则，以斜杠（/）开头表示目录，其他情况下表示文件。你可以使用通配符来匹配多个文件或目录，如 *.log 匹配所有扩展名为 .log 的文件，build/ 匹配 build 目录及其内容。

3. 注释：可以使用 # 符号添加注释，注释后的内容将被忽略。

4. 模式匹配：支持简单的通配符模式，如 *（匹配任意字符序列），?（匹配单个字符），[abc]（匹配字符 a、b 或 c），[0-9]（匹配数字）等。

5. 感叹号（!）：如果某个文件被忽略，但你希望将其包含在版本控制中，可以在规则前添加感叹号。

以下是一个示例 .gitignore 文件的内容：

# 忽略编译生成的文件
build/
bin/

# 忽略日志文件
*.log

# 忽略临时文件
tmp/

# 不忽略 README.md 文件
!README.md

这个 .gitignore 文件指示 Git 忽略 build/ 和 bin/ 目录下的所有内容，所有扩展名为 .log 的日志文件，以及根目录下的 tmp/ 目录。但会保留 README.md 文件。

.gitignore 文件对于确保不必要的文件不会误入版本控制非常有用，并保持 Git 仓库整洁和高效。

git add -f 可以强制提交忽略型文件

配置命令别名

在 Git 中，你可以通过配置命令别名（alias）来简化常用的 Git 命令，提高工作效率。可以使用 git config 命令来配置别名。以下是几个常见的示例：

1. 设置全局别名：

   git config --global alias. 
   //git-command如果比较长最好用''包含起来
   

   将 替换为你想要设置的别名， 替换为对应的 Git 命令。例如，将 co 设置为 checkout 的别名：

   git config --global alias.co checkout
   

   接下来，你可以使用 git co 来代替 git checkout。

2. 设置仓库级别别名：
   如果你只想在当前仓库中使用别名，可以在仓库目录下运行相同的命令，去掉 --global 参数即可。这样别名将仅在当前仓库中生效。

3. 查看别名配置：
   使用以下命令查看当前配置的别名：

   git config --get-regexp alias
   

一些常见的 Git 命令别名示例：

• git st 代替 git status
• git br 代替 git branch
• git ci 代替 git commit
• git co 代替 git checkout
• git df 代替 git diff
• git lg 代替 git log --oneline --decorate --all --graph

你也可以组合多个命令来定义一个别名。例如，定义一个别名 git up 来执行 git fetch 和 git rebase origin/main 命令：

git config --global alias.up '!git fetch && git rebase origin/main'

使用 git up 命令时，Git 会依次执行 git fetch 和 git rebase origin/main。

通过配置命令别名，你可以根据自己的使用习惯和需要来简化 Git 命令，并提高工作效率。

双减号(–)和单减号(-)

在 Git 命令中，--（双减号）和 -（单减号）都用于传递选项或参数。它们的作用如下：

1. --（双减号）：

   • 分离位置参数和选项参数：当命令中存在位置参数和选项参数时，使用 -- 将它们分隔开，确保选项参数不会被误解为位置参数。例如：

     git diff -- somefile.txt
     

     这里的 -- 分离了 diff 命令的选项参数和位置参数 somefile.txt。

2. -（单减号）：

   • 作为选项的前缀：在 Git 命令中，很多选项都以 - 开头，并且可以连续使用多个选项。例如，git log -n 5 中的 -n 选项用于指定显示日志条目的数量。
   • 作为缩写形式的前缀：一些常用的选项有单字符和多字符两种形式。单字符选项通常以单减号作为前缀，而多字符选项则以双减号作为前缀。例如，-b 是 -branches 的缩写形式，--branches 是其完整形式。

需要注意的是，-- 和 - 在不同的上下文中可能会有不同的作用。例如，在一些命令中，-- 可能用于指定分支或文件名的结束标记，而 - 可能用于表示从标准输入读取数据。

在使用 Git 命令时，要根据具体的命令和选项来正确理解和使用 -- 和 -，并注意它们的作用范围和用途。可以通过查看 Git 的官方文档或使用 git help 命令来获取更详细的信息和示例。

---

如上便是本期的所有内容了，如果喜欢并觉得有帮助的话，希望可以博个点赞+收藏+关注❤️ ,学海无涯苦作舟,愿与君一起共勉成长