Git workflow when delivering to clients
During the last two years I’ve been using the following branching model while developing a large B2C app: A Successful Git Branching Model.
In this case, code that was merged to master was only the production one, i.e. the exact version that was deployed to the app stores.
Now that my work there is over, I’m now working on a company that develops mobile apps for various clients.
- Git: definition of upward/downward directions between branches feels counterintuitive
- Merge issues on large Git/TeamCity project with 4 releases
- Git: Merging to a branch from another branch using Kdiff3
- List all modified files in git merge commit - even the fast forwarded
- Detached HEAD in GitHub Git Client
- Git: How do I merge complex branches that have widely diverged with some missing history?
We are using pretty much the same model as above, but something annoys me.
The problem is: “production” doesn’t mean the same thing when working for a client.
Let me elaborate:
- We deliver multiple versions for client review/test on a regular basis (basically at the end of each sprint),
- We sometimes don’t deploy ourselves the app on the stores,
- Sometimes we don’t even know if the code is/will be in these stores ever.
The consensus here seems to merge code to master only when it has been pushed to production (app store or MDM). Release branches are created at the end of each sprint and go only to develop, where a tag is made.
My questions are:
- Should we merge to master whenever we deliver something to the client?
- Should we create a intermediate branch (called ‘delivery’ or ‘stage’ for example) to receive releases and keep master for real production state?