安辰

stay hungry stay foolish

发表于 更新于 分类于 阅读次数： 本文字数： 1k 阅读时长 ≈ 4 分钟

到现在我们已经学习了Git的基础知识，包括：

概念涵盖了Git 90%的功能，同样也足够满足开发者的日常需求。

然而, 剩余的10%在处理复杂的工作流时（或者当你陷入困惑时）可能就显示尤为重要了。

接下来要讨论的这个话题是“整理提交记录” ：开发人员有时会说“我想要把这个提交放到这里,那个提交放到刚才那个提交的后面”, 而接下来就讲的就是它的实现方式，看起来挺复杂, 其实是个很简单的概念。

发表于 更新于 分类于 阅读次数： 本文字数： 884 阅读时长 ≈ 3 分钟

HEAD

HEAD是一个对当前检出记录的符号引用，也就是指向你正在其基础上进行工作的提交记录。

HEAD总是指向当前分支上最近一次提交记录。大多数修改提交树的Git命令都是从改变HEAD的指向开始的。

我们可以通过下面这张图来理解：

HEAD->master->C1，HEAD指向master， master指向C1

HEAD通常情况下是指向分支名的（如bugFix）。在你提交时，改变了 bugFix的状态，这一变化通过HEAD变得可见。

如果想看HEAD指向，可以通过cat .git/HEAD查看，如果HEAD指向的是一个引用，还可以用git symbolic-ref HEAD查看它的指向。

发表于 更新于 分类于 阅读次数： 本文字数： 723 阅读时长 ≈ 3 分钟

Git存储结构

Git有四大组件，分别是：

  • Tag
  • Commit
  • Tree
  • Blob

当git初始化后，目录下就生成了.git文件夹，存放着与git相关的所有内容，我们看下目录下具体的内容：

所有的组件都存放在objects文件夹中：

发表于 更新于 分类于 阅读次数： 本文字数： 936 阅读时长 ≈ 3 分钟

git默认的是master分支，试想下，如果所有的开发都在master分支，想起来都比较混乱，那么有没有比较科学的分支策略呢？本篇将介绍git的分支策略，听我慢慢道来～

分支分类

正常分支：

  • master：主分支
  • develop：开发分支

临时分支：

  • feature：功能分支
  • release：预发布分支
  • fixbug：修补bug分支

发表于 更新于 分类于 阅读次数： 本文字数： 807 阅读时长 ≈ 3 分钟

在上一篇中，介绍了git的初始化配置配置、获取帮助、初始化仓库、跟踪新文件、提交、忽略某些文件，以及分支，具体文章：如何克服解决Git冲突的恐惧症？（Git基础篇–上），本篇将介绍分支合并相关的git merge与git rebase。

merge

分支合并的方法一就是git merge，通过图示更容易理解：

执行命令如下：

1
2
3
git merge bugFix
git checkout bugFix
git merge master

执行过程如下：

rebase

分支合并的方法二就是git rebase，通过图示更容易理解：

执行命令如下：

1
2
3
4
git rebase master
//下面两步只是示例，不建议使用
git checkout master
git rebase bugFix

执行过程如下：

0%