10th MXCuBE meeting - ESRF - Grenoble, France
Tuesday, 17th of January, 2017
presented by Matias Guijarro, Beamline Control Unit
Software Group, ESRF
- multiple backups
- fast operations
- works offline
- paradigm shift compared to CVS, SVN
- designed for multiple branches
- easy context switching
- enable a lot of workflows
Desired git workflow for MXCuBE projects
- "stable" master branch
- new features in branches
- pull requests (from github)
- 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
- 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
- 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
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 ?
who decides ?
what are the required steps ?
when to deprecate 2.2 ?
Check github issue
Dealing with multiple versions vs. git workflow
- 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
Longer term goals
in 18 months ?