Could anyone at RealScout comment on why you started committing directly to master? This point seemed under-examined in your blog post, despite being a very unconventional git strategy.
We don't commit directly master. We have a master branch and a dev branch. We commit directly to dev, and when we are ready to push to production with cut from dev and merge into master, then push master to prod. Pushing directly to dev keeps our repos up to date, and keeps us honest with our commits. As long as you are always pushing green tests, you can be confident in your work, and so can your team.
Shshshano's comment is technically correct - we treat our dev branch as master - or at least how I've always treated master. It's the most up-to-date and production-ready branch.
Our git strategy can be summed up with:
- Commit everything to one, main branch
- Cut production releases on a separate branch or with tags
Comments
Could anyone at RealScout comment on why you started committing directly to master? This point seemed under-examined in your blog post, despite being a very unconventional git strategy.
We don't commit directly master. We have a master branch and a dev branch. We commit directly to dev, and when we are ready to push to production with cut from dev and merge into master, then push master to prod. Pushing directly to dev keeps our repos up to date, and keeps us honest with our commits. As long as you are always pushing green tests, you can be confident in your work, and so can your team.
Shshshano's comment is technically correct - we treat our dev branch as master - or at least how I've always treated master. It's the most up-to-date and production-ready branch.
Our git strategy can be summed up with:
- Commit everything to one, main branch
- Cut production releases on a separate branch or with tags