Git 实践指南

在 Git 开发中通常会控制主干分支的质量，但有时还是会把错误的代码合入到远程主干。 虽然可以 直接回滚远程分支， 但有时新的代码也已经合入，直接回滚后最近的提交都要重新操作。 那么有没有只移除某些 Commit 的方式呢？可以一次 revert 操作来完成。

在 Git 中使用 reset 可以让当前分支回滚（reset）到任何一个历史版本， 直接移除那以后的所有提交。但这更改了 Git 的历史，Git 服务通常会禁止这样做。 这便需要一个更安全的方式将代码状态回到历史版本，同时不更改 Git 历史。 如果直接回滚会影响到最近的提交，可以参考 从 Git 历史移除某些 Commit 在回滚的同时保留最近的有效提交。 所谓 保护分支，就是指不允许改写 Git 历史的分支。在 Github 中对应的选项是 Force Pushes，该选项默认处于 Disallow 状态。

在 基于 Git/npm 的开发流程实践 中提到， Git 所做的不仅仅是同步文件，它更是一种编写和组织代码的方式。 我们知道 Commit Message 是每次 提交代码 时的附加信息， 为什么 Commit Message 是一个问题呢？ 设想这样一个场景：你发现一个最近上的功能有 Bug， 现在要马上回滚到上那个功能之前。但当你打开 git log 时看到了这样一幅场景：

如果说 SVN 改变了人们同步代码的方式，那么 Git 改变了人们写代码的方式。 在 Harttle 看来 Git 基于 commit 的管理机制让开发者可以管理每一份代码变更， 而分支、合并、衍合等 Git 操作则使得这些变更可以随意拼接， 甚至可以把昨天的一个改动拼接到今天的改动之后。 这透露了 Git 对开发过程是有观点的，而非仅仅是同步代码。要遵循这些观点才能用得顺手， 比如明确地细分每个特性（Commit）、组织这些特性所在的线条（Branch）、合入功能或版本（Merge）。 本文以开发一个 NPM 的包的场景来介绍如何高效地使用 Git。

Git已经成为当今版本控制工具的主流，而分布式的结构和日志型的存储让Git不那么容易理解。 本文以实际的案例，总结了日志相关的操作步骤以及涉及到的Git命令。

Git已经成为当今版本控制工具的主流，而分布式的结构和日志型的存储让Git不那么容易理解。 Git的一个分支相当于一个commit节点的命名指针。分支之间可互相merge。 本文以实际的案例，总结了Git远程仓库的操作步骤以及涉及到的Git命令。

Git已经成为当今版本控制工具的主流，而分布式的结构和日志型的存储让Git不那么容易理解。 Git的一个分支相当于一个commit节点的命名指针。分支之间可互相merge。 本文以实际的案例，总结了Git分支管理的操作步骤以及涉及到的Git命令。

Git已经成为当今版本控制工具的主流，而分布式的结构和日志型的存储让Git不那么容易理解。 本文以实际的案例，总结了Git代码提交相关的操作步骤以及涉及到的Git命令。主要包括：

Git已经成为当今版本控制工具的主流，而分布式的结构和日志型的存储让Git不那么容易理解。 本文以实际的案例，总结了仓库初始化的操作步骤以及涉及到的Git命令。