Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Mihini/Git Process
< Mihini
Revision as of 10:58, 19 April 2013 by Lbarthelemy.sierrawireless.com (Talk | contribs) (New page: =1. Main Approach= Taken from a discussion on mihini-dev mailing list, kudos to ffleutot. There are 3 families of Git workflows: merge, rebase, and pull requests. * Merge workflows sho...)
1. Main Approach
Taken from a discussion on mihini-dev mailing list, kudos to ffleutot.
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.
Our Choice: 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, it makes sense to show the parallelism through a merge, but this should be the exception, not the rule.