4 ms·
A nice thing about merges is: If you have CI on every PR, and you require all merges into master to be fast-forward merges, then you a) guarantee that master i
by dagss 8y ago
A nice thing about merges is:
If you have CI on every PR, and you require all merges into master to be fast-forward merges, then you a) guarantee that master is always green and b) don't need to run CI again on the master branch.
If you want a) integration tests that may take some minutes, and b) a bullet proof guarantee on always having those tests green on master...
..then I don't think linear history can be made to work (without a lot of real rebase pain in daily work). I would love to be proved wrong.
- umvi 8y ago> b) don't need to run CI again on the master branch. Not exactly true. We have a different CI pipeline run based on whether the commit is on a feature branch vs. master. On a feature branch you probably just want to make sure it builds and passes tests. On master you might want to do things like generate documentation, generate a code-coverage report (doing this on a feature branch might be very time consuming), push to production, etc.
- rakoo 8y ago> generate a code-coverage report (doing this on a feature branch might be very time consuming) I'd argue that a feature branch is the place where you want to run code-coverage reports, to make sure you improve the numbers
- dagss 8y agoI definitely want those things you say done on the feature branch. Whether push to production happens before or after integration to master isn't critical, but it should be a close 1:1 between master and prod (within minutes).
- Joky 8y agoThis is quite simplistic: it does not scale on projects with a combination many "PR" in flights (many developers) and hours of CI resources to validate.