青衫客36的博客

在使用 Git 进行版本控制时，配置user.name和user.email是一个非常重要的初始步骤，但不是绝对必须的。这两个配置项定义了当你进行提交（commit）时用于标识提交者的信息。

前面我们讨论的场景三和场景四都是在合作紧密的开发团队中使用的，这样的开发团队具有良好的信任关系，具有共同遵守的、规范的项目开发流程。原仓库的所有者审核Pull request，如果没有问题，就会合并Pull request到原仓库。（2） 可以参考前面场景一、二 、三 、四的做法，在新建的版本库中独立工作，最终将漏洞修复或其他的代码贡献同步到远程新建的版本库中。（4）原仓库的所有者审核Pull request，如果没有问题，就会合并Pull request到原仓库。（2）做一些漏洞修复或其他的代码贡献。

删除的Listener3版本的内容很可能会合并到Listener4版本，这时往往需要重新修改Listener4版本的提交日志消息，因此在完成操作之前需进入文本编辑器修改Listener4版本的提交日志。一般只 指定[startpoint]，即从某一个提交节点开始，可以使用HEAD^^，HEAD~100、commitID或者commitID的头几个字符来指定，比如下面的命令指定重新整理HEAD之前的3个提交节点。注意：不要通过git rebase对任何已经提交到远程仓库中的提交记录进行修改。

注意：默认的合并方式为“快速式合并”（fast-forward merge），会将分支里的提交合并到主分支里，并列在一条时间线上，与我们期望的呈现为一条独立的分支线段不符，因此合并时需要使用--no-ff参数关闭“快进式合并”。这样在GitHub上的分支网络图中，该工作将有一段明确的分叉合并路径。（4）最后，先切换回master分支，将最新的远程origin/master分支同步到本地存储库，再合并mybranch分支到master分支，推送到远程origin/master分支之后即完成了一项开发工作。

以下图为例，项目在A版本处开始分叉，形成了两个分支，分别提交了B、D、F和C、E、G，这时希望将这两个分支合并，只要将F与A有差异的部分放入工作区，此时C、E、G已经在工作区了，如果有冲突，解决冲突后就可以提交一个版本H，即完成了两个分支的合并。就是该次提交在Git仓库中存储的内容和头信息的校验和。简要总结一下，合并操作可以用一个公式来表示：H = A + (F - A) + (G - A)，即F版本与A版本的差异，以及G版本与A版本的差异，与A合并起来，如果有冲突，解决冲突，形成一个新的版本H。

通过克隆远程版本库从而在本地创建了一个版本库，这时就可以参照场景一的本地版本库基本用法，执行查看工作区的状态、暂存更改的文件、把暂存区提交到仓库，以及回到过去、回到未来等本地版本控制的基本操作。这时本地仓库的提交项是领先于远程仓库的，只需要通过git push将本地仓库中的提交项推送到远程仓库，即可完成本地仓库和远程仓库的同步。执行git remote -v 命令可以查看更详细的远程存储库信息，包括抓取（fetch）的远程存储库URL和推送（push）的远程存储库的URL。

注意：HEAD只是一个指向特定版本的指针，通过git reset --hard回退后，HEAD指向的不是最新版本，而git log只能查看HEAD及其之前（时间更早）的提交记录。以上两个命令的效果是放弃对特定文件或者所有文件的修改，实际上是重新checkout特定文件或者所有文件到工作区，注意，这样会覆盖掉已修改未暂存的内容。通过以下命令可以让HEAD回退到指定版本，比如HEAD^表示HEAD的前一个版本、HEAD^^表示HEAD的前两个版本，HEAD~100表示HEAD的前100个版本。