You can create a branch and pass that branch around among your instances. When you delete the branch it will be gone. you can use git rebase -i to merge your multiple, fluxxy commits in to a smaller number of good commits. You can read up on this just about anywhere.
With git and rebase you can get into the habit of committing "all the time", usually anytime something works (or even if it doesn't and you want to be able to get back to a "known bad" state). Then when you have something close to done you can collapse those into a single commit, or multiple (if you take the time to make sure each commit stands on its own).
The usual way is git rebase -i HEAD~20 (where 20 is the number of commits back you want to go) and change pick to squash where you want to combine commits. There are probably tools out there that will do this for you automatically.
Bonus git feature, git bisect for finding out which 10-line commit is the one that broke you. :)
git checkout master
# Rather than create a merge commit or a fast-forward, stage the
# effect that the merge would have to the tree:
git merge --squash wip
# Check that that looks sensible:
git diff --cached
# Now commit and write a proper commit message describing the changes:
git commit
As the other answer says, you probably want to create a new branch for your current work-in-progress as you're committing so frequently. This branch is the one that you push and pull between your private repositories. You might create that branch with:
git checkout -b wip master
Then when you want to commit, just do it with a:
git commit -m "Work in progress"
... or something similar.
If you're happy that you want to group together all the changes on the wip branch into a single commit, you can do:
git checkout master
# Rather than create a merge commit or a fast-forward, stage the
# effect that the merge would have to the tree:
git merge --squash wip
# Check that that looks sensible:
git diff --cached
# Now commit and write a proper commit message describing the changes:
git commit
After that, you should have a single new commit on master that groups together all the changes that you'd made on wip. If you do the same thing subsequently, you should still only get the additional changes that the merge would introduce as a single commit, so you don't need to worry about rebasing wip - there may be some conflicts to resolve, of course.
I think that approach (successive uses of git merge --squash wip) would work, but, if were you, I probably wouldn't do that in practice. That's because I'd like to leave behind topic branches for the new features that I decided to merge into master and be able to see those merges. Instead, I would probably take a slightly more involved approach:
Work away on the wip branch, creating lots of tiny commits.
Stop when there are some changes that make logical sense together and that can be grouped into commits and merged into master.
Think of a name for that new feature or change represented by those changes, e.g. add-menu-bar.
Create a new work-in-progress branch based on the current wip, for example with: git checkout -b wip2
Use interactive rebase to reorder and squash your commits so that those that will be part of add-menu-bar are earliest in the history after divergence from master: git rebase -i master. Note that this is rewriting the new wip2 branch and leaves the original wip branch as it was.
Find the object name (SHA1sum) of the last commit in that branch that you want to be in the topic branch add-menu-bar - let's say that's f414f31. Then create the topic branch at that commit: git branch add-menu-bar f414f31
Now merge that new topic branch into master with git checkout master && git merge --no-ff add-menu-bar.
Push your new master to anywhere that you need to.
Switch back to wip2 and rebase it onto the new master: git checkout wip2 && git rebase master.
Now you work on the new wip2 branch instead, and that's the one that you push and pull between your repositories. The reason for creating a new work-in-progress branch is that then you don't have to worry the business of force-pushing the original wip branch to the other repositories, rebasing or resetting the branch there, etc. etc.
发布评论
评论（3）
您可以创建一个分支并在实例之间传递该分支。当你删除分支时，它就会消失。您可以使用 git rebase -i 来将多个 Fluxxy 提交合并为较少数量的良好提交。您几乎可以在任何地方阅读此内容。
使用 git 和 rebase，你可以养成“一直”提交的习惯，通常是在某些事情有效的时候（或者即使它不起作用并且你希望能够回到“已知的坏”状态）。然后，当您即将完成某件事时，您可以将它们折叠成一个或多个提交（如果您花时间确保每个提交都是独立的）。
通常的方法是 git rebase -i HEAD~20（其中 20 是您想要返回的提交数量）并将
pick更改为squash> 您想要合并提交的位置。可能有一些工具可以自动为您完成此操作。额外的 git 功能，
git bisect用于找出哪一个 10 行提交是让你崩溃的。 :)You can create a branch and pass that branch around among your instances. When you delete the branch it will be gone. you can use
git rebase -ito merge your multiple, fluxxy commits in to a smaller number of good commits. You can read up on this just about anywhere.With git and rebase you can get into the habit of committing "all the time", usually anytime something works (or even if it doesn't and you want to be able to get back to a "known bad" state). Then when you have something close to done you can collapse those into a single commit, or multiple (if you take the time to make sure each commit stands on its own).
The usual way is
git rebase -i HEAD~20(where 20 is the number of commits back you want to go) and changepicktosquashwhere you want to combine commits. There are probably tools out there that will do this for you automatically.Bonus git feature,
git bisectfor finding out which 10-line commit is the one that broke you. :)正如另一个答案所说，您可能希望为当前正在进行的工作创建一个新分支，因为您提交得如此频繁。该分支是您在私有存储库之间推送和拉取的分支。您可以使用以下命令创建该分支：
然后，当您想要提交时，只需使用：
...或类似的内容即可。
如果您愿意将
wip分支上的所有更改组合到一个提交中，您可以这样做：之后，您应该在
master< 上有一个新提交/code> 将您在wip上所做的所有更改组合在一起。如果您随后执行相同的操作，您仍然应该只获得合并将作为单个提交引入的额外更改，因此您无需担心变基wip- 可能会出现一些冲突当然要解决。我认为这种方法（连续使用 git merge --squash wip ）会起作用，但是，如果是你，我可能不会在实践中这样做。这是因为我想为我决定合并到
master的新功能留下主题分支，并能够看到这些合并。相反，我可能会采取稍微复杂一些的方法：wip分支上工作，创建大量微小的提交。add-menu-bar。wip创建一个新的正在进行的分支，例如使用：git checkout -b wip2add-menu-bar的一部分，在与 master 分歧后最早出现在历史上：git rebase -i master。请注意，这将重写新的wip2分支，并保持原始wip分支不变。add-menu-bar中的该分支中最后一次提交的对象名称 (SHA1sum) - 假设它是f414f31。然后在该提交处创建主题分支： gitbranch add-menu-bar f414f31master中。 git merge --no-ff add-menu-bar。master推送到您需要的任何地方。现在，您可以在新的
wip2分支上工作，这就是您在存储库之间推送和拉取的分支。创建新的正在进行的分支的原因是，您不必担心将原始wip分支强制推送到其他存储库、在那里重新设置或重置分支的业务等等等等。As the other answer says, you probably want to create a new branch for your current work-in-progress as you're committing so frequently. This branch is the one that you push and pull between your private repositories. You might create that branch with:
Then when you want to commit, just do it with a:
... or something similar.
If you're happy that you want to group together all the changes on the
wipbranch into a single commit, you can do:After that, you should have a single new commit on
masterthat groups together all the changes that you'd made onwip. If you do the same thing subsequently, you should still only get the additional changes that the merge would introduce as a single commit, so you don't need to worry about rebasingwip- there may be some conflicts to resolve, of course.I think that approach (successive uses of
git merge --squash wip) would work, but, if were you, I probably wouldn't do that in practice. That's because I'd like to leave behind topic branches for the new features that I decided to merge intomasterand be able to see those merges. Instead, I would probably take a slightly more involved approach:wipbranch, creating lots of tiny commits.add-menu-bar.wip, for example with:git checkout -b wip2add-menu-barare earliest in the history after divergence from master:git rebase -i master. Note that this is rewriting the newwip2branch and leaves the originalwipbranch as it was.add-menu-bar- let's say that'sf414f31. Then create the topic branch at that commit:git branch add-menu-bar f414f31masterwithgit checkout master && git merge --no-ff add-menu-bar.masterto anywhere that you need to.wip2and rebase it onto the new master:git checkout wip2 && git rebase master.Now you work on the new
wip2branch instead, and that's the one that you push and pull between your repositories. The reason for creating a new work-in-progress branch is that then you don't have to worry the business of force-pushing the originalwipbranch to the other repositories, rebasing or resetting the branch there, etc. etc.squashing可能是您想要的您可以在合并（包括拉取）或变基（也可交互式）时压缩提交
squashingis probably what you wantYou can squash commits on merge (includes pull) or rebase (interactive as well)