workflow and branches

10th MXCuBE meeting - ESRF - Grenoble, France

Tuesday, 17th of January, 2017

presented by Matias Guijarro, Beamline Control Unit

Software Group, ESRF

git

  • Distributed version control system
  • Local, no server needed

- multiple backups

- fast operations

- works offline

  • Branching model

- paradigm shift compared to CVS, SVN

- designed for multiple branches

- easy context switching

- enable a lot of workflows

Desired git workflow for MXCuBE projects

  • Feature branch workflow

- "stable" master branch

- new features in branches

- pull requests (from github)

  • Many advantages

- in theory, master should not contain broken code

- facilitates Continuous Integration

- several developers can work on a new feature without disturbing the main codebase

- communication++ between developers, code review

Pull request

  • Feature branch workflow

- only 1 public repository

- pushed branches have to be merged

- source for pull request will always be from a feature branch

- destination will always be 'master' branch

  • Try to submit nice pull requests

- rebase your branch (before sharing it !)

- rewrite history: squash commits, fix wrong commit messages, fix non-atomic commits

- a pull request is both communication and code sharing

git merge

git rebase

  • much cleaner project history (no merge commits)
  • perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks
  • easier to navigate with commands like git log, git bisect, and gitk

Prefer rebase vs. merge

BUT beware: NEVER rebase a public branch !

Configure 'git pull' to do rebase instead of merge

git config --global pull.rebase true

Current MXCuBE repository state

MXCuBE 2.1
BlissFramework master
HardwareRepository master
HardwareObjects 2.1
MXCuBE 2.2
BlissFramework master
HardwareRepository master
HardwareObjects 2.2
MXCuBE 3 master
HardwareObjects 2.2

deprecated

Qt3 & Qt4

stable

Qt3

web

development

What about MXCuBE master ?

  • MXCuBE master = unstable, development version
  • links to Hardware Objects master branch
  • at some point, master Hardware Objects and master MXCuBE will become 2.3 = new stable

when ?

who decides ?

what are the required steps ?

testing ?

when to deprecate 2.2 ?

Check github issue

Dealing with multiple versions vs. git workflow

  • Introducing versions management to feature-branch workflow
  • branches, not tags

- do you find it disturbing ?

- allow for bug fixes in a version

Theoretically there should not be new features in a stable branch...

 

... but we have new features, or bug fixes that need to be ported to other branches

This should be limited to a minimum.

 

But sharing our work together has more priority !

 

So... That's life.

Middle term goals / wishes

  • 2.3 to see the light in a few months (before next MXCuBE meeting, if possible ?)
  • Hardware Objects 2.3 to all have an abstract version + a test/fake/mockup implementation
  • 2.3 Hardware Objects to be deployed at all sites

Longer term goals

  • Getting rid of BlissFramework, HardwareRepository
  • MXCuBE 2.4 to be the last MXCuBE 2 version

in 18 months ?