workflow and branches
10th MXCuBE meeting - ESRF - Grenoble, France
Tuesday, 17th of January, 2017
presented by Matias Guijarro, Beamline Control Unit
Software Group, ESRF
- 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
- 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
- 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
Current MXCuBE repository state
Qt3 & Qt4
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
who decides ?
what are the required steps ?
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 ?
git workflow and branches - MXCuBE meeting
By Matias Guijarro