Git 工作流程以及我对 Git 别名的新喜爱

不管好坏，我当前的 Git 工作流程不包括合并，而是重新定基。

它使历史记录更简洁，与既定的工作流程（相当标准的 GitHub 流程）兼容，只是没有合并提交。我试图找到一个漂亮的主分支图表，但作为一名 GitLab 的用户，在 GitLab 仓库中找到这些信息并不难，但我认为 GitHub 并没有这个历史记录功能。有人知道在 GitHub 上查看历史记录的最佳方法吗？

我们非常重视提交的有效性和提交信息。在本地分支上工作时，您可以随意提交，但在发起拉取请求之前，需要进行一次交互式的 rebase。完成几次 rebase 之后，就没什么好怕的了。我之前没有做过，而且说实话，我的第一个拉取请求非常痛苦。我觉得完成 rebase 的审核流程和清理提交历史记录的时间，跟编写功能代码的时间一样长 >_<。现在，我、rebase 和 amend 都成了朋友。我还没机会使用修复提交，但我很快就会在 Raider 上试用它们！

我喜欢用 Git Bash 来处理我的源代码仓库需求。即使我公司的工作流更复杂，对我来说，它也是最灵活的。我之前尝试过Sourcetree（它和 BitBucket 的配合比 GitHub 更好）和Git Kracken，在需要处理复杂的冲突情况时，可视化界面确实很方便，但我还是会继续使用我信赖的 Git Bash。我以前从来不喜欢用命令行，只是在某些情况下才用，但现在，尤其是在我转向 Ruby 和 Rails 之后，我几乎随时都会打开至少 3-4 个终端。昨天我甚至不用查找 Vim 就直接退出了！我觉得这应该算是一个里程碑。

我一直在使用 GIT CLI 别名，还安装了多个脚本在终端中运行（终端鹦鹉，我正看着你呢！）。其中一些对我的工作帮助更大 :)。如果你没有 Git 别名，可以自己创建一个。你只需要在~/.gitconfig

[alias]
    st = status
    ci = commit -v

我现在个人最喜欢的是：

st = 状态

co = 结帐

dm = diff –patience master

prb = 拉 –rebase

pu = 拉 –rebase origin master

pf = 推 –force-with-lease

po = 推 origin master

你的 Git 别名是什么？还有，MacOS 上的 Command+Option+Shift+V 有多棒？这才是我复制粘贴文本时无法保留旧格式的关键！