我不同意那些说“它们是一样的”或“不会发生什么坏事”的答案。
它们在一个重要的方面有明显的不同。antak described it correctly in a post，但是我想强调潜在的危险，那就是你可能会失去对新提交的跟踪。
如果你按分支 checkout ，那么分支指针将指向提交，下次提交时，新的提交将被添加，分支指针将沿着移动，这通常是人们希望发生的事情。
如果你只是通过提交来 checkout ，然后又进行了一次新的提交，那么你就没有分支指向那个新的提交，只有HEAD指向它。
如果你在这个时候 checkout 了其他分支，你可能会失去对新提交的跟踪（如果你不知道一些特殊的东西，比如ref-log，你可能会失去对它的跟踪）。
正如antak所指出的，你可以进行新的提交，然后在那一点上创建一个分支，但是如果你不知道最初问题的答案，那么你可能不知道如何去做，对吗？
简单地说：你通常想 checkout 分支，除非你有特殊的理由不这样做。

简而言之，不会发生任何不好的事情。 checkout branch更容易，并使您保持最新（即最新的commit）。通过commit checkout 可能会或可能不会 * 使您落后于分支的最新状态。

git checkout <branch>将在<branch>的最后提交处检出<branch>，即HEAD将指向该分支的最后提交。
git checkout <commit>有点不同。如果 checkout <commit>，您可以指向最新的提交，因此您将与HEAD同步。* 但是 * 您也可以checkout以前的提交，这将使您处于detached HEAD状态，例如，HEAD指向了git历史记录中的另一个提交（很可能是最近的）。你也可以重置HEAD，使其指向你 checkout 的当前提交。
通常应该在<branch>之前 checkout ，因为您总是知道您拥有分支的最新版本（除非有上游更改，否则您应该在git pull之前 checkout ）。
如果您想了解更多信息，Here是git checkout的文档。

checkout <commit>和checkout <branch>的相同之处在于，它们会对工作树中的文件和目录进行任何必要的更改，以使其最终看起来与<commit>或<branch>参数指定的提交所记录的文件状态相同。
除此之外，后者（<branch>）还将您指定的任何分支设置为活动分支。通过这样做，它完成了“在分支上”的概念。
分支只是一个可移动的标签，它赋予一个提交，自动移动到你 * 提交 * 的任何新提交。这些标签使提交更容易管理和记忆。
checkout <commit>可能会让你进入 detached state。在这种状态下，你不会得到你的自定义标签。但是你可以创建提交，然后在那个位置创建一个新的分支。除了没有被分支（或标签）标记的提交最终会在很多天后被 garbage collected 之外，是否在detached state下工作是个人喜好和/或方便的问题。

简单地说，git checkout分支_name会带你到那个分支的最近一次提交，而as会带你到一个你提到它名字的提交。