声明：这仅仅是个人意见。

在微软总部工作了6年，参与了几个产品团队的开发，我有一些感悟。

用Git命令不需要的东西。

Git rebase 没有必要。

虽然有人认为使用git rebase有很多优点，比如省去了合并提交、使提交图更易读等，但我认为这些与提交图质量对于“产品/服务的价值”并没有太大关系，所以这就是我不使用git rebase的理由。如果在私人分支上使用，我并不介意，但如果将其作为“整个团队的规定”，我认为这会适得其反，导致工作效率下降。我觉得如果有时间进行git rebase的操作，最好是转移到下一个任务上。实际上，我几乎从未见过有人使用（或者说就算有使用也看不出来）。至少我自己不使用。

用 Git cherry-pick 动作是不必要的。

个人认为，这种做法是“百害无一利”。虽然表面上看起来很方便，实际上也可能真的很方便，但我觉得这更像是一种“一次性的黑客”。例如，在修复紧急错误时，有一个流程是从开发分支派生出热修复分支来修复，并将其拾取到发布分支中，但最佳实践是相反的，应该从发布分支派生出热修复分支来修复该错误，然后将其合并到发布分支，再合并到开发分支，这样就不需要拾取了。

如果想要对某个功能进行有限发布，首先在设计中添加飞行模式功能，以使其处于“未曝光”的状态进行发布。然后，通过飞行模式设置，可以实现特定功能的“曝光”，从而达到目的。根据我的观点，让一个功能的提交是否包含在特定分支中来控制用户的访问权限，对于分支来说是负担过重。为了更接近最佳实践，个人认为应该在团队层面上不鼓励使用使用樱桃拣选技巧。

不需要使用 Git merge –squash。

有些动机可能是不想在每次提交时留下详细的消息。但是即使提交图中有许多无用的提交和提交消息，我认为在数周、数月或数年后，问题也不会成为多大问题。以前大家都会努力压缩提交，但现在很少这样做的人，是不是有很多呢？我认为与其鼓励随便提交以便压缩，不如养成”在适当的地方提交”的习惯，因为能看到提交的历史才更重要。我认为周围并没有太在意是否压缩提交的人。

只要了解了这个，Git 命令就足够了。

克隆Git

创建仓库的副本（克隆）是绝对必要的。以我为例，即使是相同的远程仓库，我也会创建多个副本。有时我同时在几个分支上进行工作。这时，我会在末尾加上数字2、3、4来克隆。

git clone https://github.com/yoshiwatanabe/test.git test2

Git添加

特别是，使用通配符将所有文件移动到暂存区（索引）的方法。

git add . 

我在日常生活中经常使用它。

错误地放入了暂存区的文件.

git reset HEAD ＜ファイルのパス＞　

将其从舞台上拖下来。

提交Git

git commit -m "コミットの目的"

我差不多能解决这个问题。

偶尔，我会使用 “–amend” 提交来补送遗漏的物品，但仅限于尚未将提交内容推送到GitHub等平台的时候。

git commit --amend

但这并不是绝对必要的。你只需要在新的提交中交付遗失物品即可。

如果有这样的情景，即被同事或上司告知将提交（commit）做成完整的，不要后来再修改遗漏的地方，如果还没有推送（push），就使用 commit –amend 来进行修改。那么这个人可能只是“过分追求完美”，当然这也取决于国家习俗和团队文化。在我所在的微软团队中，我从来没有见过那么在意提交的完整性的人。所以比起这种事情，更好的方式是尽快转移到下一个任务上。

拉取 Git

在Git中，最安全且應盡可能頻繁執行的命令是什麼？

git fetch

它能够将手上的GitHub等中心仓库的状态更新为最新的。

实际上，这个命令只是下载中央仓库的最新状态，所以仅这样做并没有太多意义。在我的工作流程中，这个命令后面会跟着git pull、git merge、git remote prune origin等（稍后会提到）。

• ネット環境がないキャンプ場で仕事する予定がある場合、同僚のトピックブランチも含めて完全に最新の状態で出発したい

 

• 同僚のトピックブランチも見える状態になるので、だれがどのあたりのコードをいじってるか分かる

git pull は実は git fetch と git merge のショートカットだという理解を深める

有许多优点。

无论哪种选择，手头的仓库保持为中央仓库的最新版本并没有什么不好的。

拉取Git

其实，git fetch也会在后台自动执行。虽然我习惯先执行git fetch，然后再执行git pull，但其实git fetch是不必要的（以前不使用”git pull”命令，而是用”git fetch”后紧跟”git merge”的组合方式）。

git pull

我可以将当前checkout中的本地分支更新为最新状态（即中央存储库中对应分支的最新状态），原因有两种情况。

我能够将当前的checkout中的本地分支更新为最新的状态，这样做有两种情况。

情境1

在处理主题分支时，如果工作仍需一段时间才能完成，可以先将预计合并的目标分支（例如：master）更新至最新版本，然后使用git merge将其合并到主题分支中。

这个任务非常重要。因为如果我的主题分支（包括将要合并的目标分支的内容）落后，那么同事们就会越来越频繁地犯错，例如重新修复已经修复过的错误，错过了同事们已经优化的方便机制，或者无意中修复了同事们已经删除的旧代码中的错误等。

如果经常发生，冲突发生时的规模就会较小，这样避免麻烦。

在中国，只需要使用一种选项来翻译以下句子：「シチュエーション２」。

在开始编码之前，也就是在创建新的主题分支之前，尽可能地以最新的状态（即中央仓库中该分支的最新提交）作为起点，为了新任务的完成。

Git合并

在情景1中，大部分情况下会使用git merge，这个场景是在执行git pull操作后。

偶尔，我会根据同事推荐的即将完成的主题分支将其合并到我的工作分支中，这时候必须假设同事已经通过git push将相关分支推送到中央仓库。

切换到 Git 分支

有两个情景

情境1

在中文的口语中是这样的：“在不同的分支之间来回切换，也就是为了将工作目录切换到不同分支的状态。特别是在将正在进行中的话题分支与目标分支（例如：主分支）合并时，进行一系列操作使其保持最新。”

git checkout master
git pull
git checkout topics/task2
git merge master

就像checkout一样进行移动。

以下是用中文对“シチュエーション２”的描述：
场景２

在创建新主题分支时，可以使用”-b” 参数来表示”创建新分支并切换到该分支”的意思。

git checkout -b topics/task3

我会做到。

推送Git

git push

我通常会使用它将我的分支上传到中央仓库。我的工作经常以git push结束。通过将它推送到中央仓库，可以确认它已经被云存储备份，即使我的笔记本不小心在某处被水淹没，我当天的工作内容也不会丢失。

最终目标分支（例如：主分支）不使用push，而是使用拉取请求（pull request）。拉取请求不是Git的核心功能，但是是一种常见的方法。

删除 Git 远程仓库的无效分支。

这也是一种安全的Git命令。用于清理分支。

git remote prune origin

我会从 git fetch 开始做。这是一个安全命令，只要尝试使用，就可以轻松理解。

手中的中央仓库可能包含一些在像GitHub这样的中央仓库中已经被删除的分支。因为开发者通常在专题分支的任务完成后会将其删除。

使用该命令后，手头的中央仓库也能删除不存在的中央仓库分支。

当你输入git branch -v后，会列出分支的列表。

  dev/topics/integration    37f95b9f9 [gone] add integration test
  dev/topics/topic3         711e639e2 [gone] adds unit test for logout feature
  dev/master                e8468657b initial poc load test

我可以看到手头的分支正在追踪一个已经不存在的分支。在这种情况下，

git branch -d dev/topics/topic3

在等等对分支进行清除或删除。

以下是中文的释义：
“ブランチが” –> “分支存在”

Git分支-v

为了使我们手头的分支能够跟踪已经不存在的中央仓库的分支，我们使用上面提到的方法。

删除 Git 分支

这也是已经提到过的，希望尽量清理手头的分支，以防止数量过多。

总结

我在我个人的工作流程中介绍了一些不常用的Git命令和经常使用的Git命令。