1. 合并分支
如将dev分支合并到master上。
git checkout master
git merge dev
当master分支所在的提交是dev分支的直接祖先，git会执行fast-forward（—ff）合并，不会创建新的提交commit，而是会将要dev的提交commit直接合并到master分支。
当master分支所在的提交不是dev分支的直接祖先，那么 git 将会执行 no-fast-forward（—no-ff） 合并。使用 no-fast-forward 合并时，Git 会在当前活动分支上创建新的 merging commit。这个提交指向master分支和dev分支。
2. 合并冲突
当我们想要合并的两个分支的同一文件中的同一行代码上有不同的修改，或者一个分支删除了一个文件而另一个分支修改了这个文件时，就会产生冲突。当尝试合并这些分支时，Git 会向你展示冲突出现的位置。我们可以手动移除我们不想保留的修改，保存这些修改，再次添加这个已修改的文件，然后提交这些修改。
3. 变基rebase
使用 rebase 命令会将提交到某一分支上的所有修改都移至另一分支上。我们执行 rebase 的分支总是含有我们想要保留的最新近的修改！这样我们不会遇到任何合并冲突，而且可以保留一个漂亮的、线性的 Git 历史记录。如果你在开发一个 dev分支并且 master 分支已经更新过，那么变基就很好用。你可以在你的分支上获取所有更新，这能防止未来出现合并冲突。
如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。
4. 交互式变基Interactive Rebase
在我们正在 rebase 的提交上，我们可以执行以下 6 个动作：
- reword：修改提交信息；
- edit：修改此提交；
- squash：将提交融合到前一个提交中；
- fixup：将提交融合到前一个提交中，不保留该提交的日志消息；
- exec：在每个提交上运行我们想要 rebase 的命令；
- drop：移除该提交。
5. 重置Resetting
git reset 能让我们不再使用当前台面上的文件，让我们可以控制 HEAD 应该指向的位置。
软重置会将 HEAD 移至指定的提交（或与 HEAD 相比的提交的索引），而不会移除该提交之后加入的修改。输入 git status 后，我们仍然可以访问在之前的提交上做过的所有修改。这很好，这意味着我们可以修复这些文件的内容，之后再重新提交它们！
有时候我们并不想保留特定提交引入的修改。不同于软重置，我们应该再也无需访问它们。Git 应该直接将整体状态直接重置到特定提交之前的状态：这甚至包括你在工作目录中和暂存文件上的修改。
6. 还原
另一种撤销修改的方法是执行 git revert。通过对特定的提交执行还原操作，我们会创建一个包含已还原修改的新提交
7. 挑选（cherry pick)
当一个特定分支包含我们的活动分支需要的某个提交时，我们对那个提交执行 cherry-pick！对一个提交执行 cherry-pick 时，我们会在活动分支上创建一个新的提交，其中包含由拣选出来的提交所引入的修改。
8. 取回（fetching)
通过在这个远程分支上执行 git fetch，我们就可在本地获取这些修改。这不会以任何方式影响你的本地分支：fetch 只是单纯地下载新的数据而已。
9. 拉取（pulling）
尽管 git fetch 可用于获取某个分支的远程信息，但我们也可以执行 git pull。git pull 实际上是两个命令合成了一个：git fetch 和 git merge。当我们从来源拉取修改时，我们首先是像 git fetch 那样取回所有数据，然后最新的修改会自动合并到本地分支中。
10.reflog
git reflog是一个非常有用的命令，可以展示已经执行过的所有动作日志。如果犯了错，可以根据reflog提供的信息通过重置HEAD来轻松重做
原文链接：dev.to/lydiahallie…
