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)

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

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 ?