git .git目录提交

I use Git every day and I wrote a Git guide and a Git Cheat Sheet in the past.

我每天都使用Git，过去我写过Git指南和Git备忘单 。

I consider myself a Git fan, but …I’m not an expert of Git.

我认为自己是Git的粉丝，但是...我不是Git的专家。

Commit, fetch origin, pull origin, push to origin.. that’s my day-to-day of using Git.

提交，获取原点，拉原点，压入原点..这就是我每天使用Git的时间。

And I do some Git:

我做一些 Git：

The advanced things that Git can do blow my mind. It can be very complex, and I tend to avoid all that complexity. I almost never use Git in the command line, and use GitHub Desktop which is the simplest and nicest Git client ever.

Git可以做的高级事情让我震惊。 它可能非常复杂，我倾向于避免所有这些复杂性。 我几乎从不在命令行中使用Git，而使用GitHub Desktop ，这是有史以来最简单，最出色的Git客户端。

Two things I do however use sometimes are cherry-picking and squashing commits.

但是，有时候我要做的两件事是摘樱桃和压榨提交 。

Let’s talk about that.

让我们来谈谈。

In projects where I’m the only developer, which means all my personal projects, I do tend to work on master when I can. For example if I’m doing a simple change, or adding a new post to the blog. Fast and non-breaking stuff.

在我是唯一开发人员的项目中，这意味着我所有的个人项目，我都会在可能的情况下倾向于使用master。 例如，如果我要进行简单的更改，或者将新帖子添加到博客中。 快速且不间断的东西。

In some cases however I do not use this approach, and instead I create a branch for a big feature.

但是，在某些情况下，我不使用这种方法，而是为大型功能创建分支。

This is also the default when working on a team-based or open source project.

这也是基于团队或开源项目工作时的默认设置。

You create a branch, and commit often. Committing early and often is a great advantage because you can work on your code with the confidence that you can always return back to a working state, or at least to a state you know that something worked.

您创建一个分支，并经常提交。 尽早且经常进行提交是一个很大的优势，因为您可以放心地编写代码，使您始终可以返回到工作状态，或者至少返回到您知道某些工作有效的状态。

You might do a series of quick commits where the message is “ok”, “trying this”, or “fix dumb mistake”.

您可能会执行一系列快速提交，其中消息是“确定”，“尝试执行此操作”或“修复愚蠢的错误”。

But at some point you need to converge to a stable state and commit the changes back to master, or to any branch you want.

但是在某些时候，您需要收敛到稳定状态并将更改提交回master或您想要的任何分支。

You want to do one thing before that: squashing your commits.

在此之前，您想做一件事：压缩提交。

GitHub can do that for you automatically when you are merging a Pull Request, and it’s a workflow I’ve been using a lot on public Open Source repositories in the past.

合并合并请求请求时， GitHub可以自动为您执行此操作，这是我过去在公共开放源代码存储库中经常使用的工作流程。

Instead of seeing all the individual commits contained in a Pull Request, you only see one commit, and in the PR merge process you can write a detailed and dedicated commit message and description.

您只看到一个提交，而不是看到“拉取请求”中包含的所有单个提交，在PR合并过程中，您可以编写详细的专用提交消息和描述。

This will eliminate all the previous Git commits that diverge from the head of the branch you’re merging to, and also remove all those commits where maybe you reverted changes, and so on.

这将消除所有先前与合并分支的分支不同的Git提交，并删除所有您可能还原了更改的提交，依此类推。

This is squashing in the GitHub PR process. You can squash your commits outside of GitHub, too.

这正在压榨GitHub PR流程。 您也可以在GitHub之外压缩提交。

Once your work on a branch is done, you merge master (or any other branch where you want to merge) into it:

在分支上完成工作后，将母版(或您要合并的任何其他分支)合并到其中：

git merge master

so you can handle any update conflict there.

因此您可以在那里处理任何更新冲突。

Then you checkout master, and from there you run:

然后您检出master，然后从那里运行：

git merge --squash <your-feature-branch>

and then

然后

git commit

This is just one of the possible workflows you can use, and doing all using GitHub is very simple and the option that can give you the least amount of headaches.

这只是您可以使用的可能工作流程之一，并且使用GitHub完成所有工作非常简单，并且该选项可以使您头疼最少。

翻译自: https://flaviocopes.com/git-squash/

git .git目录提交