Tidy or drop git history for release? [closed]

问题

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

I am going to publicly release a project, hopefully to find contributors. My project is a local clone of another active and well-resourced project (a Django project template). I haven't made any deep changes to the code, although it is now a different project.

My current git history is a mess and not very helpful. I will clean it up somehow before public release and, of course, make clear what the original forked project was. Since I don't think there's anything special or mystifying about the modifications I've made to the project (mainly customisations), I'm keen to squash all commits as per this Stack Overflow post. I wonder if this is bad practice as it may make it even a bit harder to contribute to if I drop the indexed search history. I intend to reduce such problems with good comments, a considered README, etc.

The alternative I see and wish to avoid is a painstaking incremental rebase squash mission.

回答1:

I understand that you have

1. forked from a project on GitHub,
2. cloned your fork,
3. made a number of commits in that local repo.

In case you have already pushed to your fork

Because your (untidy) history is now public, some people may have already forked/cloned it to build upon your work. By rewriting your history and then force pushing to your fork, you run the risk of pissing those people off... big time! That's bad practice.

So, before proceeding, you should at least make sure that your project was never forked or cloned. Fortunately, GitHub keeps track of that information. In the right-hand side navigation bar, click on Graphs.

The Network tab will show you how many people forked your project.

If you're the only one listed there, good. Then go to the Traffic tab, to see how many times your project was cloned.

If your project has never been cloned, there is still time to force push your tidied history to your fork.

One caveat: of course, there is always a risk that someone forks/clones your old, untidy history just in the nick of time before you force push. Proceed with care.

In case you have not yet pushed anything to your fork

In that case, rewriting your history is completely safe, and is considered good practice.

All you have to decide is the level detail you wish to retain in the new, tidied history. It's really up to you, but, as you rewrite history, try to put yourself in the shoes of someone browsing that history and trying to make sense of your improvements/changes.

For instance, if the changes you brought to the original project are substantial, squashing all your commits into one massive commit may not be the best idea... Make your history more pedestrian by spreading your changes over several commits, in a logical manner.

Here is a relevant passage of the Pro Git book:

[...] try to make each commit a logically separate changeset. If you can, try to make your changes digestible — don’t code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. Even if you don’t commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. If some of the changes modify the same file, try to use git add --patch to partially stage files (covered in detail in Chapter 6). The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes. This approach also makes it easier to pull out or revert one of the changesets if you need to later.

来源：https://stackoverflow.com/questions/25607119/tidy-or-drop-git-history-for-release