On Wed, 6 Jan 2016 18:42:06 +0100, Luc Maisonobe wrote:
Le 06/01/2016 15:56, Gilles a écrit :
Hi.
I've reread this article (which IIRC was advertised on this list
some
time ago):
http://nvie.com/posts/a-successful-git-branching-model/
It is quite clear and I think that it would easy to get used to.
Yes, it is quite a good model.
Unless there are shortcomings that would prevent its use with the CM
repository, I propose that we adopt it officially, and assume its
nomenclature in order to eventually develop scripts similar to
what is mentioned below.
That would be fine with me. One should however be aware that we
cannot delete branches in Apache git repository anymore (at least
I think this is something that is now enforced). The reason is
that history should never be lost, or rewritten. So everything
that hits the repository remains there.
Considering this, having very short lived hotfix branches may
prove unpractical. I would not like on the other hand having
such short lived branches fly around outside of Apache infrastructure
(like github or anything), as these would defeat the purpose of
preserving history.
However, using more topic branches seems good to me. This is what
was done for the field-doe (and the branch is still there).
Given the "git" model, it would make sense to allow deleting
branches whose sole purpose is to allow developers to exchange
work that is experimental.
Deleting a "feature" branch is not deleting history. The code
would become history only when this branch is merged in
"development".
IIUC, you have preserved all the history of your commits when
merging your work into "master". [By the way, I think that
it would be better to squash one "feature" into a single
commit so that it is trivial to figure out whether this
commit introduced some problem (as is advised in the article
IIUC). The detailed history of a "feature" work is not
necessary since even if a bug is uncovered, it is unlikely
that one will search for a commit to be reverted rather than
make a new one with the fix! And it will avoid a flood of
messages to the ML which only code archaeologists would ever
read.]
So (from the article),
* the "master" branch is the one from which tags for released
code are made and is of course "history",
* the "develop" branch is "history";
and those must not be deleted, obviously.
If we want to avoid the proliferation of short-lived branches
that are also "history" (of hot fixes and releases), we could
perhaps further simplify the model and have two long-lived
branches:
* "hotfix" for hot fixes, and
* "release" for release candidates.
In the latter, a tag is enough to indicate the commit that is
the target of the vote (IIUC).
[Anyway, this point is fairly moot, as we don't expect many
hot fixes or releases in CM...]
But the "feature" branches, why keep them?
The code that is in such a branch will become "history" once
it is merged into "develop" (and only in that case, if we follow
the convention).
Keeping all those short-lived branches is as if files in the
"home" directories were archived and the owner would be
forbidden to delete his own files...
Or, suppose that I'd create a hypothetical branch, in which I
would suddenly start to do some crazy stuff to the RNG code...
Wouldn't we want to be able to delete this ASAP? 8-/
So, in summary, it is sufficient to enforce a "no delete" policy
only for the "history"-making branches: "master", "develop",
"hotfix" and "release".
We should be allowed to delete anything else (if I did not miss
anything).
Best,
Gilles
best regards,
Luc
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
