【前端开发环境】前端使用GIT管理代码仓库需要掌握的几个必备技巧和知识点总结

1. git的三种状态

已提交 committed已暂存 staged已修改 modified

2. git的三个区域

git仓库是 git 用来保存项目的元数据和对象数据库的地方。 这是 git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。暂存区域暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 git 仓库目录中。 有时候也被称作`‘索引’’，不过一般说法还是叫暂存区域。工作目录工作目录是对项目的某个版本独立提取出来的内容。 这些从 git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。

3. 基本的 git 工作流程

在工作目录修改文件暂存文件，将文件的快照放入暂存区提交更新，找到暂存去文件，将快照永久性存储到 git 仓库目录。

3.1 用户信息

[!note]
当安装完 git 应该做的第一件事就是设置你的用户名称与邮件地址。 这样做很重要，因为每一个 git 的提交都会使用这些信息，并且它会写入到你的每一次提交中，不可更改。

git config --global ur.name "huyaocode"git config --global ur.email johndoe@example.com

3.2 加入暂存区

git add 文件名或路径

3.3 忽略文件

创建一个.gitignore文件，可描述需要忽略的文件。 参考

# no .a files*.a# but do track lib.a, even though you're ignoring .a files above!lib.a# 只忽略当前文件夹下已 todo 为名的文件/todo# 忽略当前目录下 build 这个文件夹build/# ignore doc/notes.txt, bu中国文化的英文t not doc/rver/arch.txtdoc/*.txt# ignore all .pdf files in the doc/ directorydoc/**/*.pdf

3.4 状态修改

git status -s将每个修改状态以一行展示，也可以用git status多行展示。

a 新添加到暂存区中的文件m 修改过的文件d 被删除的文件mm 出现在右边的 m 表示该文件被修改了但是还没放入暂存区，出现在靠左边的 m 表示该文件被修改了并放入了暂存区。?? 未跟踪

3.5 查看修改

要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --cached 或 git diff --staged

3.6 提交修改

运行git commit，会出现如下情况。这种方式会启动文本编辑器，开头还有一空行，供你输入提交说明。下面的行是被注释了的，也可以取消这些注释。

一般是vim 或 emacs。当然也可以按照 起步 介绍的方式，使用 git config --global core.editor 命令设定你喜欢的编辑软件。

也可以使用git commit -m "修改描述三生石三生路" 这种直接输入描述的方式提交修改。

git commit 加上 -a 选项，git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤

3.7 移除文件

要从 git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。
可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。

运行 git rm记录此次移除文件的操作。下一次提交时，该文件就不再纳入版本管理了。 如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母）。 这是一种安全特性，用于防止误删还没有添加到快照的数据，
这样的数据不能被 git 恢复。

想把文件从 git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。(不想让git跟踪)

git rm --cached 某文件

3.8 文件更名

git mv file_from file_to

其实，运行 git mv 就相当于运行了下面三条命令：

mv readme.md readmegit rm readme.mdgit add readme

3.9 查看提交历史

[!note]
git loggit log 会按提交时间列出所有的更新，最近的更新排在最上面。 正如你所看到的，这个命令会列出每个提交的 sha-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。

使用 -p 用来限制展示条数。git log -p -2

使用 --stat 选项看到每次提

使用format，定制要显示的记录格式。

使用--graph可形象地展示你的分支、合并历史。

$ git log --pretty=format:"%h %s" --graph* 2d3acf9 ignore errors from sigchld on trap* 5e3ee11 merge branch 'master' of git://github.com/dustin/grit|\| * 420eac9 added a method for getting the current branch.* | 30e367c timeout code and tests* | 5a09431 add timeout protection to grit* | e1193f8 support for heads with slashes in them|/* d6016bc require time for xmlschema* 11d191e merge branch 'defunkt' into local

3.10 重新提交

[!note]
有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交。

git commit --amend

这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息。

文本编辑器启动后，可以看到之前的提交信息。 编辑后保存会覆盖原来的提交信息。

例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

git commit -m 'initial commit'git add forgotten_filegit commit --amend

最终你只会有一个提交 – 第二次提交将代替第一次提交的结果。

3.11 取消暂存的文件

使用 git ret head <file> 来取消暂存。在调用时加上 –hard 选项可以令 git ret 成为一个危险的命令（译注：可能导致工作目录中所有当前进度丢失！）

3.12 撤消对文件的修改

使用git checkout -- <file> 可以撤销修改（未保存到暂存区）

4. 什么是 git 复刻（fork）？复刻（fork）、分支（branch）和克隆（clone）之间有什么区别？

复刻（fork） 是对存储仓库（repository）进行的远程的、服务器端的拷贝，从源头上就有所区别。复刻实际上不是 git 的范畴。它更像是个政治/社会概念。克隆（clone）不是复刻，克隆是个对某个远程仓库的本地拷贝。克隆时，实际上是拷贝整个源存储仓库，包括所有历史记录和分支。分支（branch） 是一种机制，用于处理单一存储仓库中的变更，并最终目的是用于与其他部分代码合并。

5. “拉取请求（pull request）”和“分支（branch）”之间有什么区别？

分支（branch） 是代码的一个独立版本。拉取请求（pull request） 是当有人用仓库，建立了自己的分支，做了些修改并合并到该分支（把自己修改应用到别人的代码仓库）。

6. “git pull”和“git fetch”之间有什么区别？

简单来说，git pull 是 git fetch + git merge。

当你使用 pull，git 会试着自动为你完成工作。它是上下文（工作环境）敏感的，所以 git 会把所有拉取的提交合并到你当前处理的分支中。pull 则是 自动合并提交而没有让你复查的过程。如果你没有细心管理你的分支，你可能会频繁遇到冲突。

当你 fetch，git 会收集目标分支中的所有不存在的提交，并将这些提交存储到本地仓库中。但git 不会把这些提交合并到当前分支中。这种处理逻辑在当你需要保持仓库更新，在更新文件时又希望处理可能中断的事情时，这将非常实用。而将提交合并到主分支中，则该使用 merge。

7. 如在 git 恢复先前的提交？

假设你的情形是这样，其中 c 是你的 head，(f) 是你文件的状态。

   (f)a-b-c    ↑  master   (f)a-b-c    ↑  master要修改提交中的更改：git ret --hard head~11git ret --hard head~1现在b是 head，因为你使用了 --hard，所以你的文件将重置到提交 b 时的状态。要撤销提交但保留更改：git ret head~11git ret head~1现在我们告诉 git 将 head 指针移回（后移）一个提交（b），并保留文件原样，然后你可以 git status 来显示你已经检入 c 的更改。撤销提交但保留文件和索引：git ret --soft head~11git ret --soft head~1执行此操作后，git status，你讲看到索引中的文件跟以前一致。

8. 什么是“git cherry-pick”？

[!note]
命令 git cherry-pick 通常用于把特定提交从存储仓库的一个分支引入到其他分支中。常见的用途是从维护的分支到开发分支进行向前或回滚提交。

这与其他操作（例如：合并（merge）、变基（reba））形成鲜明对比，后者通常是把许多提交应用到其他分支中。

小结：

git cherry-pick <commit-hash>1git cherry-pick <commit-hash>

9. 解释 forking 工作流程的优点?

forking 工作流程 与其他流行的 git 工作流程有着根本的区别。它不是用单个服务端仓库充当“中央”代码库，而是为每个开发者提供自己的服务端仓库。fo杨桃的营养价值rking 工作流程最常用于公共开源项目中。

forking 工作流程的主要优点是可以汇集提交贡献，又无需每个开发者提交到一个中央仓库中，从而实现干净的项目历史记录。开发者可以推送（push）代码到自己的服务端仓库，而只有项目维护人员才能直接推送（push）代码到官方仓库中。

当开发者准备发布本地提交时，他们的提交会推送到自己的公共仓库中，而不是官方仓库。然后他们向主仓库提交请求拉取（pull request），这会告知项目维护人员有可以集成的更新。

10. 告诉我 git 中 head、工作树和索引之间的区别？

该工作树/工作目录/工作空间是你看到和编辑的（源）文件的目录树。该索引/中转区（staging area）是个在 /.git/index，单一的、庞大的二进制文件，该文件列出了当前分支中所有文件的 sha1 检验和、时间戳和文件名，它不是个带有文件副本的目录。head是当前检出分支的最后一次提交的引用/指针。

11. 你能解释下 gitflow 工作流程吗？

[!note]
gitflow 工作流程使用两个并行的、长期运行的分支来记录项目的历史记录，分别是 master 和 develop 分支。

master，随时准备发布线上版本的分支，其所有内容都是经过全面测试和核准的（生产就绪）。hotfix，维护（maintenance）或修复（hotfix）分支是用于给快速给生产版本修复打补丁的。修复（hotfix）分支很像发布（relea）分支和功能（feature）分支，除非它们是基于 master 而不是 develop 分支。develop，是合并所有功能（feature）分支，并执行所有测试的分支。只有当所有内容都经过彻底检查和修复后，才能合并到 master 分支。feature，每个功能都应留在自己的分支中开发，可以推送到 develop 分支作为功能（feature）分支的父分支。

12. 什么时候应使用 “git stash”？

[!note]
git stash 命令把你未提交的修改（已暂存（staged）和未暂存的（unstaged））保存以供后续使用，以后就可以从工作副本中进行还原。

回顾：

$ git statuson branch masterchanges to be committed:new file: style.csschanges not staged for commit:modified: index.html$ git stashsaved working directory and index state wip on master: 5002d47 our new homepagehead is now at 5002d47 our new homepage$ git statuson branch masternothing to commit, working tree clean$ git statuson branch masterchanges to be committed:new file: style.csschanges not staged for commit:modified: index.html$ git stashsaved working directory and index state wip on master: 5002d47 our new homepagehead is now at 5002d47 our new homepage$ git statuson branch masternothing to commit, working tree clean我们可以使用暂存（stash）的一个地方是，如果我们发现在上次提交中忘记了某些内容，并且已经开始在同一分支中处理下一个提交了：# assume the latest commit was already done# start working on the next patch, and discovered i was missing something# stash away the current mess i made$ git stash save# some changes in the working dir# and now add them to the last commit:$ git add -u$ git commit --ammend# back to work!$ git stash pop# assume the latest commit was already done# start working on the next patch, and discovered i was missing something# stash away the current mess i made$ git stash save# some changes in the working dir# and now add them to the last commit:$ git add -u$ git commit --ammend# bac我们的新老师作文k to work!$ git stash pop

13. 如何从 git 中删除文件，而不将其从文件系统中删除？

如果你在 git add 过程中误操作，你最终会添加不想提交的文件。但是，git rm 则会把你的文件从你暂存区（索引）和文件系统（工作树）中删除，这可能不是你想要的。

换成 git ret 操作：

git ret filename # or
echo filename >> .gitingore # add it to .gitignore to avoid re-adding it
1
2
git ret filename # or
echo filename >> .gitingore # add it to .gitignore to avoid re-adding it
上面意思是，git ret 是 git add 的逆操作。

14. 是么时候使用“git reba”代替“git merge”？

[!note]
这两个命令都是把修改从一个分支集成到另一个分支上，它们只是以非常不同的方式进行。

考虑一下场景，在合并和变基前：

a <- b <- c [master]
^
d <- e [branch]
1
2
3
4
a <- b <- c [master]
^
d <- e [branch]
在 git merge master 之后：

a <- b <- c
^ ^
d <- e <- f
1
2
3
4
a <- b <- c
^ ^
d <- e <- f
在 git reba master 之后：

a <- b <- c <- d <- e
1
a <- b <- c <- d <- e
使用安徽技校变基时，意味着使用另一个分支作为集成修改的新基础。

14.1 何时使用

如果你对修改不够果断，请使用合并操作。
根据你希望的历史记录的样子，而选择使用变基或合并操作。

14.2 更多需要考虑的因素

分支是否与团队外部的开发人员共享修改（如开源、公开项目）？如果是这样，请不要使用变基操作。变基会破坏分支，除非他们使用 git pull –reba，否则这些开发人员将会得到损坏的或不一致的仓库。你的开发团队技术是否足够娴熟？变基是一种破坏性操作。这意味着，如果你没有正确使用它，你可能会丢失提交，并且/或者会破坏其他开发者仓库的一致性。分支本身是否代表有用的信息？一些团队使用功能分支（branch-per-feature）模式，每个分支代表一个功能（或错误修复，或子功能等）。在此模式中，分支有助于识别相关提交的集合。在每个开发人员分支（branch-per-developer）模式中，分支本身不会传达任何其他信息（提交信息已有作者）。则在这种模式下，变基不会有任何破坏。是否无论如何都要还原合并？恢复（如在撤销中）变基，是相当困难的，并且/或者在变基中存在冲突时，是不可能完成的。如果你考虑到日后可能需要恢复，请使用合并操作。

参考资料

git在线学习：/d/file/titlepic/8323617