# 版本控制系统 有了它我们就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，我们可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因 ## 集中式： 集中式版本库集中存放于一个单一的中央服务器的，保存所有文件的修订版本。在协同工作时，人们需要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 ## 分布式： 分布式版本控制系统根本没有“中央服务器”， 我们每次是把代码仓库完整地镜像下来，包括完整的历史记录。这使得每个人的电脑上都是一个完整的版本库，不仅仅是最新版本的文件快照。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。同时，我们也不需要像联网就可以进行工作。 但是在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能我们不在一个局域网内，两台电脑互相访问不了。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑或者服务器，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。这也是我们在GitHub建立repo的原因。 为了减小git存储大小使用压缩算法。 Git存储全部历史版本和最新版本。 # Git实践 ## Git 快照的本质 Git 并不会像一些版本控制系统那样每次保存文件的完整副本（比如 Subversion）；相反，Git 会对文件的状态进行索引，利用快照（snapshot）来记录文件的内容。每次执行 git commit 时，Git 会将 暂存区（staging area） 中的文件状态保存为一个新的快照。  这个快照并不是直接存储文件本身，而是存储文件内容的哈希值。  具体来说，Git 对每个文件生成一个唯一的 **SHA-1 哈希值**，并通过这些哈希值来追踪每个文件的变化mit 和快照 **git commit`** 是保存快照的主要时机。当你执行 commit 时，Git 会：  扫描暂存区中的所有文件，检查哪些文件被修改或新增。  生成一个新的快照来记录这些文件的内容（每个文件的哈希值）。  这时，Git 并不会记录所有文件的实际内容，而是通过哈希值来引用这些内容。这使得 Git 存储的版本信息相当高效 。 Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 **快照流**。 Git 中所有的数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。 Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。 这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样： 24b9da6552252987aa493b52f8696cd6d3b00373 Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。 Git默认保存文件快照，即保存每个文件每个版本的完整内容。 ## Git初始配置 当我们安装好Git后，还需要在Git bash或者terminal进行一些相关设置，以下设置仅需设置一次即可。 git config --global user.name "Your Name" git config --global user.email "email@example.com" 除此之外，Git还有很多设置，包括常用编辑器等，大家可以键入以下命令查看自己的设置并进行修改。 git config –list ## Git初级命令 在学习完本章之后，你应该能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。 本章也将向你演示了如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览你的项目的历史版本以及不同提交（commits）之间的差异、如何向你的远程仓库推送（push）以及如何从你的远程仓库拉取（pull）文件。 ### 在已存在目录中初始化仓库 通常有两种获取 Git 项目仓库的方式： 将尚未进行版本控制的本地目录转换为 Git 仓库； 从其它服务器 克隆 一个已存在的 Git 仓库。 在 Windows 上： $ cd /c/user/my_project 之后执行： $ git init 该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪。 ### 在已存在文件的文件夹中进行版本控制 如果在一个已存在文件的文件夹（而非空文件夹）中进行版本控制，你应该开始追踪这些文件并进行初始提交。 可以通过 git add 命令来指定所需的文件来进行追踪，然后执行 git commit ： ### 克隆现有的仓库 这时就要用到 git clone 命令。Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。 当你执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库 （虽然可能会丢失某些服务器端的钩子（hook）设置，但是所有版本的数据仍在，详见 在服务器上搭建 Git ）。 git clone （克隆仓库） 会自动设置master分支 ### 更新到仓库 现在我们的机器上有了一个 真实项目 的 Git 仓库，并从这个仓库中检出了所有文件的 工作副本。 通常，你会对这些文件做些修改，每当完成了一个阶段的目标，想要将记录下它时，就将它提交到仓库。 请记住，你工作目录下的每一个文件都不外乎这两种状态：已跟踪 或 未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区（to be commited）。简而言之，已跟踪的文件就是 Git 已经知道的文件。 工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们， 而你尚未编辑过它们。 编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 在工作时，你可以选择性地将这些修改过的文件放入暂存区，（git add）然后提交所有已暂存的修改，如此反复。 ## 检查当前文件状态 $ git status On branch master 现在分支名是“master”，这是默认的分支名。 Your branch is up-to-date with 'origin/master'. 该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。 意味着没有任何未推送的更改。通过这条信息可以确认当前分支的状态没有任何新变化。 nothing to commit, working directory clean 这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。 此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。这里的“工作目录干净”意味着所有已跟踪的文件都是未修改状态，也没有新增文件或更改内容。 #### 文件的状态 Git的文件可以处于以下几种状态： - **未跟踪（Untracked）**：新文件，尚未被Git纳入版本控制。 - **已跟踪（Tracked）**：文件已经被Git加入到版本控制中，Git会记录它的历史。已跟踪的文件可以处于以下状态： - **未修改（Unmodified）**：文件没有做任何修改。 - **已修改（Modified）**：文件内容发生了变化，但尚未放入暂存区。 - **已暂存（Staged）**：文件修改已被加入暂存区，等待提交。 1、 git add：这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。git add 命令使用文件或目录的路径作为参数；如果参数是目录的路径，该命令将递归地跟踪该目录下的所有文件。 好吧，实际上 Git 只不过暂存了你运行 git add 命令时的版本。 如果你现在提交，CONTRIBUTING.md 的版本是你最后一次运行 git add 命令时的那个版本，而不是你运行 git commit 时，在工作目录中的当前版本。 所以，运行了 git add 之后又作了修订的文件，需要重新运行 git add 把最新版本重新暂存起来： 2、 一旦你将文件从暂存区提交到本地版本库（使用 git commit 命令），它的状态会变成“未修改”状态，前提是没有做新的修改。提交会将文件的当前快照保存到版本库中，并更新历史记录。此时，这个文件不再处于暂存区，因为它的内容已经被记录到版本库。 如果 git status 命令的输出对于你来说过于简略，而你想知道具体修改了什么地方，可以用 git diff 命令。 稍后我们会详细介绍 git diff，你通常可能会用它来回答这两个问题：当前做的哪些更新尚未暂存？ 有哪些更新已暂存并准备好下次提交？ 要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff： 若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --staged 命令。 这条命令将比对已暂存文件与最后一次提交的文件差异： 如果想要查看已暂存内容的区别，可以使用 d 或 6（区别）命令。 它会显示暂存文件的一个列表，可以从中选择想要查看的暂存区别。 这跟你在命令行指定 git diff --cached （git diff --staged）非常相似： #### 四个区 **工作区**：这是你本地的开发目录，文件在此处进行修改。是我们直接编辑的地方 **暂存区**：是一个临时区域，用于保存那些已准备好提交的文件修改，只有文件进入暂存区，它才会在下一次提交时被包含在内。可在工作区和版本库之间进行数据的友好交流。**"Changes to be committed"** 正是指那些已经添加到暂存区，但尚未被提交到版本库的文件。“Changes not staged for commit”指的是还未被放入暂存区的文件。 **本地版本库（Git 仓库）**：只有经过提交（commit）的更改才会保存在这里。存放已经提交的数据，push 的时候，就是把这个区的数据 push 到远程仓库了。 **远程仓库（Remote Repository）**：远程仓库是用于共享和备份的地方，通常是托管在GitHub、GitLab等平台上的。你通过 git push 将本地仓库的提交推送到远程仓库，或者通过 git pull 从远程仓库获取更新。 基本的 Git 工作流程如下： 1. 在工作区中修改文件。 2. 将你想要下次提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区。 3. 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录。 如果 Git 目录中保存着特定版本的文件，就属于 **已提交** 状态。 如果文件已修改并放入暂存区，就属于 **已暂存** 状态。 如果自上次检出后，作了修改但还没有放到暂存区域，就是 **已修改** 状态。 #### 忽略文件 在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件的模式 #### 提交更新 在此之前，请务必确认还有什么已修改或新建的文件还没有 git add 过， 否则提交的时候不会记录这些尚未暂存的变化。 这些已修改但未暂存的文件只会保留在本地磁盘。 所以，每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了， 然后再运行提交命令 git commit： #### 移除文件 要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。 可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。 另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。 换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。 为达到这一目的，使用 --cached 选项：$ git rm --cached README git rm 命令后面可以列出文件或者目录的名字，也可以使用 glob 模式。 ### 查看提交历史 git log 的常用选项 列出了我们目前涉及到的和没涉及到的选项，以及它们是如何影响 log 命令的输出的： 这里的主角就是 commit 后跟的 40 位的字符，这个值是一个 SHA-1 哈希值。它是对内容和头信息 Header 的一个校验和 checksum，Git 使用 SHA-1 并不是为了数据的安全性，而是数据的完整性；它保证，在很多年后，你重新 checkout 某个 commit 时，一定是当时的状态，完全一摸一样。 通过在 git log后增加 --pretty=oneline简化输出内容；当 oneline 或 format 与另一个 log 选项 --graph 结合使用时尤其有用。 这个选项添加了一些 ASCII 字符串来形象地展示你的分支、合并历史 想查看某次提交信息，可以通过 git show 来查看，如: ，记录中可能有为数不少的合并提交，它们所包含的信息通常并不多。 为了避免显示的合并提交弄乱历史记录，可以为 log 加上 --no-merges 选项。 Git reflog ### 清理文件 **对于一些不需要的文件或目录，你需要的是清理它而不是保存修改记录，git clean就是用来做这个事情的** **需要注意的是，这个命令会移除未被跟踪的文件，可以考虑执行 git stash --all 来移除所有文件并保存到栈上。** **Git 提供了一个grep命令，可以很方便的从提交历史，工作目录，甚至索引中查找一个字符串或者正则表达式。** **通过git log可以很强大的知道一些特定的提交信息。** **如通过-S选项知道内容的新增和删除提交记录** ### 子模块 通过 git submodule add 添加子模块, **子模块的作用**：Git 子模块的核心思想是将另一个 Git 仓库的特定提交嵌入到当前项目中。通过这种方式，子模块是独立的 Git 仓库，但它与父仓库关联，并且通常会指向某个特定的提交（即子模块的“版本”）。当你不在那个目录中时，Git 并不会跟踪它的内容，而是将它看作子模块仓库中的某个具体的提交。 尽管 Git 会“跟踪”子模块，但它并没有将子模块的具体内容（即其历史和文件）直接包含到父仓库的版本控制中。相反，父仓库只会记录子模块仓库当前的提交ID。所以，如果你对子模块进行修改并提交，这些修改不会自动反映到父仓库中，你需要显式地更新父仓库中的子模块引用。 **自动提交子模块状态**：它会将子模块的当前状态（即引用的提交）记录在父仓库中。也就是说，Git 会将子模块引用的提交（即子模块的 HEAD）存储在父仓库的索引（暂存区）中。 **添加到暂存区**：子模块目录会被视作一个单独的 Git 仓库，而父仓库会将其作为一个特定提交的引用添加到暂存区。实际上，父仓库的变化并不是对子模块内容的直接修改，而是对子模块的指针（即某个特定提交的引用）进行记录。 子模块是独立的 Git 仓库，因此你可以进入子模块目录，并像管理普通 Git 仓库一样管理它。你需要使用以下命令来更新、获取最新的子模块内容： - git submodule update：根据父仓库记录的提交更新子模块。 - git submodule update --remote：获取远程子模块仓库的最新版本。 - git submodule status：查看当前子模块的状态。 **更改父仓库 main 分支**：只会影响子模块的引用，而不会自动影响子模块内容。如果要更新子模块内容，需要手动更新并同步。 **更改子模块**：如果更改仅限于子模块本身，它不会直接影响父仓库。但如果你提交并更新子模块的引用，父仓库会跟踪这些更改，进而影响 main 分支。 git submodule update --remote：获取远程子模块仓库的最新版本。 **我们在 clone 一个含子模块的项目时，默认是不会包含子模块内容的，只有目录，需要使用如下命令初始化和更新子模块：** **git submodule init** **git submodule update** ### 打包 **git 提供了多种网络传输的方法，如 SSH、HTTP 等，但是还有种不太常用的功能又什么有效。** **Git 可以就将它的数据"打包"到一个文件中，通过 git bundle来实现。bundle 命令会将git push命令所传输的所有内容打包成一个二进制文件，你可以将这个文件转发给别人，然后解包到仓库中。** **虽然 git log --oneline origin/main..main 和 git log --oneline main ^origin/main它们实际上提供的是相同的信息，即 本地分支 main 上的提交，远程 origin/main 分支没有的提交。** **5. Git 命令中的排除和选择语法** **在 Git 中，使用 ^ 进行排除的语法非常常见，特别是在需要精确选择提交时。以下是常用的几种表达方式：** - **main ^5de18d5：表示选择 main 分支上所有提交，但排除 5de18d5 之前的提交。** - **main~1：表示选择 main 分支上最近的提交（即 HEAD 提交）之前的一个提交。** - **main..dev：表示选择从 main 分支到 dev 分支的所有提交。** ### 撤消操作 有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令来重新提交： $ git commit --amend 当你在修补最后的提交时，与其说是修复旧提交，倒不如说是完全用一个 新的提交 替换旧的提交， 理解这一点非常重要。 例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交， 但是却意外地输入 git add * 暂存了它们两个。如何只取消暂存两个中的一个呢？ git status 命令提示了你：Changes to be committed: (use "git reset HEAD ..." to unstage) 如果你并不想保留对 CONTRIBUTING.md 文件的修改怎么办？ 你该如何方便地撤消修改——将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？ 幸运的是，git status 也告诉了你应该如何做。Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) 请务必记得 git checkout -- 是一个危险的命令。 你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。 除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令。 如果你仍然想保留对那个文件做出的修改，但是现在仍然需要撤消，我们将会在 Git 分支 介绍保存进度与分支， ## 远程仓库的使用 #### 添加远程仓库 如果想查看你已经配置的远程仓库服务器，可以运行 git remote 命令。 它会列出你指定的每一个远程服务器的简写。 如果你已经克隆了自己的仓库，那么至少应该能看到 origin ——这是 Git 给你克隆的仓库服务器的默认名字： 我们在之前的章节中已经提到并展示了 git clone 命令是如何自行添加远程仓库的， 不过这里将告诉你如何自己来添加它。 运行 git remote add 添加一个新的远程 Git 仓库，同时指定一个方便使用的简写： $ git fetch 这个命令会访问远程仓库，从中拉取所有你还没有的数据。 执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。 如果你使用 clone 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。 所以，git fetch origin 会抓取克隆（或上一次抓取）后新推送的所有工作。 必须注意 git fetch 命令只会将数据下载到你的本地仓库——它并不会自动合并或修改你当前的工作。 当准备好时你必须手动将其合并入你的工作。 如果你的当前分支设置了跟踪远程分支（阅读下一节和 Git 分支 了解更多信息）， 那么可以用 git pull 命令来自动抓取后合并该远程分支到当前分支。 这或许是个更加简单舒服的工作流程。默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或其它名字的默认分支）。 运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。 #### 推送到远程仓库 首先，我们可以使用git remote -v查看远程库的详细信息。会显示我们可以抓取或推送的origin地址。 git push 当我们需要推送本地分支到远程时，需要指定具体的本地分支，否则为工作区所在分支 git remote 和git pull先必须有.git文件 在 Git 中，**远程仓库**（origin）和**本地分支**（如 master）是两个不同的概念，但它们之间是有联系的。简单来说，origin 是远程仓库的一个默认名称，而 master 是本地仓库的一个默认分支名称。 **关系** 1. **origin 是远程仓库的引用**：origin 是 Git 默认给远程仓库起的名字。当你克隆一个 Git 仓库时，Git 会自动将远程仓库命名为 origin。你可以将它看作是远程版本的“指向标”。实际上，origin/master 是你本地仓库指向远程 master 分支的一个引用（不是实际的分支）。 2. **master 是本地分支**：master 是你本地 Git 仓库的一个分支。每个 Git 仓库都会有一个 master 分支（除非你选择了不同的默认分支名称），这个分支存储了本地的提交历史。 3. **origin/master 与 master 的区别**： - origin/master：指向远程仓库（origin）中的 master 分支的提交，表示远程仓库的当前状态。 - master：是你本地的 master 分支，它可能与远程的 origin/master 有不同的提交历史。 **举个例子** 假设你从远程仓库克隆了一个仓库，Git 会自动创建 origin 这个远程引用，以及你本地的 master 分支。此时，origin/master 就是指向远程仓库 master 分支的状态。 假设你做了一些本地更改并提交到了 master 分支。你的本地 master 分支与远程仓库的 master 分支可能已经不同步了。 bash 复制编辑 \# 拉取远程仓库的更新到本地 git fetch origin \# 查看本地 master 和远程 origin/master 之间的差异 git diff master origin/master \# 如果想要将本地的更新推送到远程仓库 git push origin master 在这里： - git fetch origin 会获取远程仓库 origin 的最新提交，但不会改变你当前的工作状态，只是更新了 origin/master。 - git diff master origin/master 会显示你本地 master 和远程 origin/master 之间的差异。 - git push origin master 会将你本地 master 分支的提交推送到远程仓库的 master 分支。 总结来说，origin 和 master 分别代表远程仓库和本地分支，origin/master 是远程仓库中 master 分支的引用，而本地的 master 是你当前分支的实际工作区域。 ## 打标签 默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样——你可以运行 git push origin 。 删除标签 git tag -d git push :refs/tags/ ## 如何回溯版本 **重置reset** **多次修改并多次提交** **前进或者后退** **Git reset –hard同步移动本地库、暂存区和工作区** **Git reset –-mixed工作区不动，保留修改，本地库、暂存区移动** **Git reset –-soft本地库移动，暂存区和工作区不动** **1. git checkout HEAD^** - **行为**：切换到上一个提交（HEAD^），但不会改变当前分支的指针。 - **效果**： - 你的工作目录会更新为上一个提交的状态。 - 你处于“分离头指针”（detached HEAD）状态，即当前不在任何分支上。 - 你可以查看或测试上一个提交的内容，但不会影响当前分支的历史。 - 如果你在分离头指针状态下做了修改并提交，这些提交不会属于任何分支，除非你显式地创建一个新分支来保存它们。 - **适用场景**：查看历史版本的内容，而不改变当前分支的状态。 **2. git reset --hard HEAD^** - **行为**：将当前分支的指针移动到上一个提交（HEAD^），并强制更新工作目录和暂存区以匹配该提交。 - **效果**： - 当前分支的指针会回退到上一个提交。 - 工作目录和暂存区会被重置为上一个提交的状态。 - 所有未提交的更改（包括未暂存的和已暂存的）都会被丢弃。 - **适用场景**：彻底回退到上一个版本，丢弃当前的所有更改。 创建一个新文件，add commit，然后删除了这个文件,然后又add commit如何恢复？ Git reset –hard 重置状态到文件没有删除的本地库版本即可 # Git 分支管理 Git最重要的运用场景是多人协同开发，但是如何能保证每个人之间的开发不影响其他人的开发进程，Git 分支的出现就是解决了这个问题，使得每个人之间的开发是独立的，互不影响的。 ## 创建分支 Git branch xx创建新分支 Git branch -v查看分支情况 git checkout 分支的切换 \# 使用git merge 进行合并 git merge issue102 创建新分支时，Git并不会将整个master分支的文件物理复制一遍，而是创建一个指向master当前状态（即HEAD指向的提交）的新的指针。因此，新分支issue从技术角度讲并不是一个完整的复制，而是一个基于master分支的“视图”或“快照”些内容。当你在master分支上执行git branch issue（或者使用git checkout -b issue）时，新分支issue将包含： - **所有文件内容**：issue分支继承了master分支上的所有文件和文件夹。 - **提交历史**：issue分支也继承了master分支直到创建点的所有提交记录 。 - **文件改动**：master分支有未提交的更改，issue分支也会包含这些更改 。 有时候分支的合并不会一番顺利，当我们在两个分支中对同一个文件的同一个部分进行了不同的修改并且commit时候，Git就没有办法顺利的合并他们，会在合并的时候产生合并冲突。比如我们在issue102分支和master分支下对issue102.md文件进行了修改，当我们将issue102分支融合到主分支上时就会发生冲突 *master——在master分支 在Git中没有什么分支是不可以删除的（除了当前所在的分支不能删除），包括master分支也是可以进行删除。 Git的分支删除可以分为删除本地分支和远程分支。 \# branchName 是需要删除的本地分支名字 git branch -d branchName git branch -m oldBranchName newBranchName 当我们想要将改名后的分支推送到远程时，我们需要进行如下操作： git branch -m oldBranchName newBranchName # 将本地的分支进行重命名 git push origin newBranchName # 将新的分支推送到远程 git push --delete origin oldBranchName issue分支与master记录间隔开了 许多使用 Git 的开发者都喜欢使用这种方式来工作，比如只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。这样，在确保这些已完成的主题分支（短期分支，比如之前的 issue102 分支）能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。 短期分支也可以叫做主题分支，它的作用是用来实现某一种特性或者相关工作（修复bug，开发产品新特性）。比如当我们的产品出现了bug时，我们应该新建一个分支并起名为bug分支，并在该分支上进行bug的修复，等我们的代码确定不会引起其他bug时，我们就可以合并到主分支上进行修复。当我们看见issue时，我们也可以使用同样的方式来解决issue的问题。常见的短期分支还有上面提到的develop，topic分支。在实际开发中，我们应该按照以下几个基本原则进行分支开发工作流程 1. master分支应该是最稳定的，也就是仅用来发布新版本，平时不能直接在上面进行操作，应该保存在远程。 2. 短期分支是我们干活的分支，短期分支可以不用上传到远程，当我们完成了bug的修复，新功能的开发时才需要合并到主分支上。 3. 多使用分支来进行开发工作。 ## 拉取远程分支 **1. stable 分支不存在** - **如果你尝试查看一个名为 stable 的分支，但该分支不存在，Git 会报此错误。** - **解决方法：** - **检查本地是否有 stable 分支：** **git branch** - **检查远程是否有 stable 分支：** **git branch -r** **如果远程有 stable 分支，但本地没有，可** **以创建该分支：** **git branch stable origin/stable** **会创建一个新的 stable 分支，并将其设置为跟踪远程的 origin/stable 分支。并且该分支的内容将与 origin/stable 一致。** **（git checkout -b stable 相当于创建新的分支git branch stable，git checkout stable因此如果存在同名分支则会报错）** **查看远程分支通过后加参数-r** **查看本地分支列表通过git branch查看** **$ git fetch origin stable : stable** **From https://github.com/datawhalechina-git-samples/app** *** branch stable -> FETCH_HEAD** *** branch HEAD -> FETCH_HEAD** *** branch stable -> FETCH_HEAD** **$ git fetch origin stable :stable** **From https://github.com/datawhalechina-git-samples/app** *** branch stable -> FETCH_HEAD** *** [new ref] HEAD -> stable** **以上均只是类似git branch stable，即复刻了main的快照，并没有将origin/stable复制下来** **除此之外，单纯git branch stable 之后你再用git fetch origin stable :stable会报错** **$ git fetch origin stable :stable** **fatal: refusing to fetch into branch 'refs/heads/stable' checked out at 'F:/usr/** **q1'** **你只能在其它分支上调用这条语句，尽管如此和$ git fetch origin stable** **一样，并没有起到从origin/stable复制，依然单纯快照。即使你再git checkout stable，是main的快照** **$ git fetch origin stable** **From https://github.com/datawhalechina-git-samples/app** *** branch stable -> FETCH_HEAD** **1. git branch stable 的功能** **git branch stable 这个命令的作用是创建一个新的本地分支，名为 stable，但它 不会切换到 该分支上。也就是说，这个命令只是在当前的分支上 创建一个新的分支，但是你的 HEAD（当前检出分支的指针）依然停留在你当前所在的分支上。** **Switched to a new branch 'stable'** **2. git checkout stable 的功能** **git checkout stable 的作用是 切换到 已经存在的 stable 分支（如果这个分支存在的话，即便没在你的工作区但是fetch了）。如果该分支已经创建并存在，执行该命令后，Git 会将 HEAD 指针指向 stable 分支，并更新工作目录的内容，使其与 stable 分支的最新状态相匹配。即跟踪fetch来的origin/stable。** **branch 'stable' set up to track 'origin/stable'.** **Switched to a new branch 'stable'** **综上，为了跟踪来自origin/stable ，要么克隆后git branch stable，要么git fetch后git checkout stable** **当你在工作时， Git 会在后台保存一个引用日志（reflog）， 引用日志记录了最近几个月你的 HEAD 和分支引用所指向的历史。 你可以使用 git reflog 来查看引用日志** **当你修改大量文件后，希望将改动拆分成多个提交而不是一起提交的时候，可以通过如下命令操作。** **如果运行 git add 后加 -i 或者 --interactive 选项的时候，Git 会进入一个交互式命令模式，** ** staged：表示文件在暂存区（staged area）中的状态。** ** unstaged：表示文件在工作目录中的状态。** **staged unstaged path** **1: unchanged +1/-1 src/trace/events.go** **表示此文件原版本已经暂存（unchanged），但是工作区已经发生改变，后面接着文件名** **如果想要查看已暂存内容的区别，可以使用 d 或 6（区别）命令。 它会显示暂存文件的一个列表，可以从中选择想要查看的暂存区别。 这跟你在命令行指定 git diff --cached 非常相似：** **在使用 Git 进行版本控制时，开发者常常需要在不同的分支之间切换，以处理不同的任务。然而，当在当前分支上进行了一些修改后，直接切换到另一个分支可能会导致冲突或丢失未提交的更改。** **Git Stash 的作用** **为了解决这个问题，Git 提供了 git stash 命令。该命令允许开发者将当前工作目录和暂存区的修改保存起来，并恢复到干净的工作状态。这样，开发者可以安全地切换到其他分支，处理紧急任务，待完成后再返回原分支，恢复之前的修改，继续工作。** **（如果尝试切换则会报错：$ git checkout stable** **error: Your local changes to the following files would be overwritten by checkout:** ​ **src/trace/events.go** **Please commit your changes or stash them before you switch branches.** **error: Your local changes to the following files would be overwritten by checkout:** ​ **src/trace/histogram.go** ​ **src/trace/histogram_test.go** **Please commit your changes or stash them before you switch branches.** **Aborting** **）** # git内部文件 ├── *config 配置信息(比如本地repo是否大小写敏感, remote端repo的url, 用户名邮箱等) ├── description 无需关心（仅供GitWeb程序使用） ├── *HEAD 目前被检出的分支 ├── index 保存暂存区信息 │ │ ├── hooks/ 钩子脚本（执行Git命令时自动执行一些特定操作） ├── info/ 包含一个全局性排除文件 │ └── exclude 放置不希望被记录在 .gitignore 文件中的忽略模式 ├── logs/ 记录所有操作 ├── *objects/ 存储所有数据内容 │ ├── SHA-1/ 保存git对象的目录（三类对象commit, tree和blob） │ ├── info/ │ └── pack/ └── *refs/ 存储指向数据（分支、远程仓库和标签等）的提交对象的指针 ├── heads/ ├── remotes/ └── tags/ （一开始缺少index和logs，objects里缺少SHA-1,refs缺少tags） **. 什么是对象？** objects目录下存储三种对象：数据对象（blob），树对象（tree）和提交对象（commit）。 5个子目录的含义如下图所示：2个blob, 2个tree和1个commit Git默认保存文件快照，即保存每个文件每个版本的完整内容。但假设只更改了某大文件中的一个字符，保存两次全部内容是不是有点低效？ Git最初向磁盘存储对象时采用"松散"对象格式；但为了节省空间和提高效率，Git会时不时将多个对象打包成一个称为"包文件"。 当版本库中有太多的"松散"对象，或者手动执行 git gc 命令，或者向远程服务器执行推送时，Git 都会进行打包。 运行以下命令，手动打包 Git把一些常用的 SHA-1 值存储在文件中，用文件名来替代，这些别名就称为**引用**。有三种引用类型：heads, remotes和tags。 运行以下命令，更新refs目录下的内容