Loading...
 

Git Workflow

 Summary

Tiki needs a customized adaptation of the GitFlow and GitLab workflows focusing on using release branches and minor release tagging.

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

 Git workflows

A quick overview of existing git related workflow suggestions, best practices. If something is missing, please add to the list below.

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” codebase, this model gives every developer a server-side repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

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:

  • 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.

Page last modified on Friday 26 August, 2016 12:44:24 GMT-0000

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools