整理或放弃git的发布历史记录？ [英] Tidy or drop git history for release?

问题描述

我打算公开发布一个项目，希望能找到贡献者。我的项目是另一个活跃且资源充足的项目（Django项目模板）的本地克隆。我没有对代码做过任何深刻的修改，尽管它现在是一个不同的项目。

我目前的git历史很混乱，并且没有多大帮助。我将在公开发布之前以某种方式清理它，当然，还要明确原始分支项目是什么。由于我不认为对项目所做的修改（主要是定制）有任何特别的或神秘的含义，因此我希望根据此：
$ b

[ ...]尝试使每个提交在逻辑上独立的变更集。如果可以的话，尽量让你的变化易于理解 - 不要在整个周末针对五个不同的问题编码，然后在周一作为一个大规模的提交提交。即使您在周末没有提交，也可以在周一使用暂存区域将您的工作分成至少一次提交，每次提交一个有用的消息。如果某些更改修改了同一个文件，请尝试使用git add - patch 来部分定义文件（详见第6章）。无论您进行一次提交还是五次，分支尖端的项目快照都是相同的，只要所有更改都是在某个时间点添加的，所以当他们必须检查更改时，请尝试让开发人员更容易。如果您以后需要，此方法还可以更容易地取出或还原其中一个更改集。

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.

解决方案

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.

这篇关于整理或放弃git的发布历史记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！