| Re: [mihini-dev] Git workflow |
|
Hi Fabien, I’m not sure how many independent contributors / complexities / long-running feature branches you expect, but in my experience the history of most Eclipse projects
is fairly linear. Many project still operate pretty much in the CVS way : Edit+commit my code on local master, Pull+Rebase (==cvs update), then push. Even a fairly large, fairly
old project like the CDT has only 33 public branches. It’s simple and efficient. There is a nice Wiki from Platform-releng about using git “the CVS way”: http://wiki.eclipse.org/Platform-releng/Git_Workflows What you call “Merge Workflows” has become very easy and clean with Gerrit. Each independent change to review is an automatic branch in Gerrit, but the Gerrit
branches are usually not publicly visible; Gerrit cares for the build verification and merge back to master once reviewed/accepted. If you look at the tip of the CDT history, you see many red tags which are each actually the tip of an automatic Gerrit branch
which don’t show up in the final history when you scroll back a bit. https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/ http://wiki.eclipse.org/Gerrit Some projects (like egit) use Gerrit reviews for each and every item, others (like CDT and TCF) work in a more hybrid way (Gerrit for external contributions
and reviews where desired, but direct “CVS way” commits to master are allowed). Your call how to proceed, but it really isn’t rocket science once you’ve got used to it a bit. HTH, Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development Tools,
Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: mihini-dev-bounces@xxxxxxxxxxx [mailto:mihini-dev-bounces@xxxxxxxxxxx]
On Behalf Of Fabien Fleutot There are a couple of organizational decisions to make, to transition Mihini into a truly open-source, open-development project. One of them is how to use Git; this post is intended to start the ball rolling. When Mihini was a closed-source project handled by a small team sharing the same office, we had very few Git usage rules, and that proved to be good enough. The situation is likely to become trickier, though: we'll
have to handle external contributions, and external contributors will rely on online docs, including Git history, more than on coffee-machine discussions to figure out how the project works. There are 3 families of Git workflows: merge, rebase, and pull requests.
·
Merge workflows show branching and merging in the public repository. They represent the way we develop more truthfully, but they tend to turn into an unreadable spaghetti mess.
·
In rebase workflows, before committing a set of changes, we graft them onto the top of the master branch *at commit time*, rather than when the feature's development started. It forces to rewrite history, but rewritten history
is more readable.
·
Finally, pull requests is the Linux way: there's only one integrator per authoritative repo, he pulls changes from development repos when he receives pull requests. To me, it seems both over-engineered for a project of our size,
and at odds with Eclipse's habits of trusting several committers on a project. The basic merge workflow is to stay on our local master branch, and to perform "git pull; git push" whenever the changes are to be published. For the rebase workflow, all developments must be done on short-lived, local branches ("git checkout -b newfeature"). When the feature or bug fix is completed, we fetch the changes which occurred on master ("git
fetch origin"), graft our commits on top of it (in branch newfeature, "git rebase master; git checkout master; git merge newfeature"), and push the resulting linear history back to Eclipse ("git push origin master"). It's often interesting to make the rebase
interactive ("git rebase -i master"), to clean-up history before putting it back into master. In the common case where all the feature commits should be squashed into a single one, there's a "git rebase --squash master" option which does that without further
questions. My personal opinion: we want our Git history to be welcoming to other people, i.e. readable. The normal workflow should be the rebase one, and each commit should make sense by itself functionally (fixing one bug,
providing one feature). In exceptional cases, where long developments went on in parallel for a long time, as happened e.g. when we switched the Airvantage protocol to M3DA, it makes sense to show the parallelism through a merge, but this should be the exception,
not the rule. I'm sure there are people here with relevant experiences and advices, either on high-level workflows or on Git command details! |