What
Before we can Migrate to Git, we need to have a strategy for how to work with it. git comes with a very powerful set of tools to work with the version control history It is absolutely not necessary to know or even use all those tools (pull, commit and push will probably cover way more than 80% of your daily work), but this makes it possible to create any kind of workflow for different kinds of use cases starting out with a simple look-alike of the centralised SVN workflow and adapting that will most likely be a good way to start, but it would be too limiting and a waste of possibilities to restrict ourselves to this.
Suggestion
A fitting workflow model for the Tiki Community should look something like the following:
- master becomes former trunk
- create branches for each Tiki major version (12, 13, 14, etc.)
- these branches are long-lived, never destroyed
- only Bug-Fixes go here
- minor versions are tags on the branches (12.1, 12.2, 13.1, etc.)
- bug fixes
- done on the lowest applicable version branch
- merge up into higher version branches
- master is the highest version, so merge into it last
- Example: security fix in 12 -> merge to 15 -> merge to 16 -> merge to 'master'
- Use git features to ease the workload: create a local hotfix branch e.g. "secfix" -> merge that hotfix branch into all applicable release branches
- Usage of feature branches:
- Devs will most likely use them locally for development.
- If they want to publish proposals for discussion, they can do so on their own sf.net/github.com account (depending on where we are hosted) with ease.
- Feature branches in the official Tiki repository should be discouraged. They might be interesting though for bigger developments/revamps like Bootstrap, Zend 3 and similar, where multiple people are working on the implementation, don't want to interfere with day-to-day development, but still need a public space to discuss these issues that will concern the whole Tiki Community.
To keep the Tiki community's open (some can call it "anarchistic") development model, push rights should be given out more or less liberally just as commit rights before. This way the centralised SVN-workflow is still available for anyone understanding and committing to the three rules. At the same time the Tiki Community can harness the power of the distributed git development model and accept pull requests from one-off committers, e.g. single line bug fixes of a power user.
How others do it
1) Centralized workflow
Summary: continue as you did before using SVN, but take advantage of local repositories and git merging. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.
How it could work for Tiki: Tiki has multiple branches, so it would not work
Conclusion: not suitable as it is (too simple for Tiki)
Read more: https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
2) Feature Branch Workflow / Github workflow
Quick summary: all feature development takes place in a dedicated branch instead of the master branch. The Feature Branch Workflow still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature.
How it could work for Tiki: Tiki multiples releases (eg: LTS branches), so this will not work, This workflow considers one active release and branches are short lived, and only for feature development.
Conclusion: not suitable as it is (but feature branches are worth considering)
Read more: https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
3) GitFlow workflow
Quick summary: It advocates a master branch and a separate development branch as well as supporting branches for features, releases and hotfixes. The development happens on the develop branch, moves to a release branch and is finally merged into the master branch. Git flow is a well defined standard but its complexity introduces problems.
How it could work for Tiki: not suitable as it is (it has the overheasd the develop branch that Tiki does not need, it assumes again one product which not the case)
Conclusion: close to what Tiki needs, but needs adaptation to the community
Read more: https://about.gitlab.com/2014/09/29/gitlab-flow/
4) Gitlab flow
Quick summary: There are flows for production branch, enviornment branches and release branches. The release branches suggestion says, that the stable branch uses master as a starting point and is created as late as possible. By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches. After a release branch is announced, only serious bug fixes are included in the release branch. If possible these bug fixes are first merged into master and then cherry-picked into the release branch.
Compared to GitFlow, it removes development branch and hotfix/feature branches.
How it could work for Tiki: close to what Tiki needs, but needs adaptation to the community
Conclusion: Simplification of GitFlow, close to what Tiki needs, but needs adaptation to the community
Read more: https://about.gitlab.com/2014/09/29/gitlab-flow/
5) Forking workflow
Quick summary: Instead of using a single server-side repository to act as the “central” co
How it could work for Tiki: Every Tiki developer would fork the official Tiki repo on github and would work there. Only official TIki repo admins could pull from these repositories.
Conslusion: Not likely
Read more: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
More food for thought:
- https://www.atlassian.com/git/tutorials/comparing-workflows/
- easy-to-read quick introduction with comparions
- read this first
- http://nvie.com/posts/a-successful-git-branching-model/
- This is the mother of all git branching strategies
- It is being perceived as too complicated by many, but this criticism comes mostly from Continuous Integration/Deployment kind of projects. For Tiki's release based model it is still a very good fit, even though it might be worth considering simplifying it.
- http://scottchacon.com/2011/08/31/github-flow.html
- A simplified version of the first branching model
- Geared towards the non-release, Continuous Deployment kind of development style that GitHub uses internally for their own product.
- Missing release branches that are needed for Tiki.
- https://about.gitlab.com/2014/09/29/gitlab-flow/
- A very elaborate definition of a workflow based on the before mentioned models.
- It tries to fix some (perceived) inconveniences of the previous models.
- Focuses on combining feature driven development and feature branches with issue tracking.
- A very elaborate definition of a workflow based on the before mentioned models.
- https://danielpocock.com/comment/12733
- How the others did the migration from SVN to Git on sf.net
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}