Git branches problem
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'd say that it was a bad idea to push changes directly onto the release branch if someone else was working on related code. That's going to cause merge conflicts. It happens but you should try to avoid it. You can use
git merge --strategy-option theirsto resolve the conflicts when you merge prioritizing any changes on the release branch, orgit merge --strategy-option oursto prioritize your (the dev) branch. If some of your fixes rely on the same code that was changed in the release branch though you might have issues and should consult with the team about overwriting the release changes with yours (assuming your fixes are equivalent to the release fixes). My 2 cents. EDIT: Also, is this an open-source project? I find it odd they would force only your code to be validated/checked while they're pushing changes directly to the release branch with no regards to other branches. -
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Don't try to do it from your desk. Talk to people.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I'd say that it was a bad idea to push changes directly onto the release branch if someone else was working on related code. That's going to cause merge conflicts. It happens but you should try to avoid it. You can use
git merge --strategy-option theirsto resolve the conflicts when you merge prioritizing any changes on the release branch, orgit merge --strategy-option oursto prioritize your (the dev) branch. If some of your fixes rely on the same code that was changed in the release branch though you might have issues and should consult with the team about overwriting the release changes with yours (assuming your fixes are equivalent to the release fixes). My 2 cents. EDIT: Also, is this an open-source project? I find it odd they would force only your code to be validated/checked while they're pushing changes directly to the release branch with no regards to other branches.Nah it's for work. I had a long list of bug and feature to work on. Meanwhile the release / pilot product had issue (hey those were on Jira) and some independent fix were applied on that production build. For the simple reason they wouldn't want to deploy (untested / unvalidated) feature / bug fixes I was working on. So you have the silly version of that: Code has bug X, fix it in dev branch. But product has bug X too! Fix it in release branch (separately) since we don't want new feature (i.e. whole of dev branch) in prod branch. Makes only so far as I was also working on new and/or breaking feature (including database schema change) The whole process seems largely clunky to me.. Not sure ow to fix it though...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
**Short answer:** Have you considered a commit by commit merge from dev to prod using [`git cherry-pick`](https://git-scm.com/docs/git-cherry-Git - pick)[^]? **Long answer:** As for the overall strategy, I'd say it is wrong! Whoever authorised changing the production branch should be taken out back and given a damned good explaination of how and when to change a branch! Let's start at the very beginning... `master` is the head revision of *released code*. No development should be checked in here, this is your latest and greatest release to the wild. `production` should be `master` plus anything `being deployed`. Again no development! The only commits are part of building the artifacts for release. Once built *and tested* it is merged back to `master` as the last step of the release. `development` is where all the changes being prepared for release go. And no, you can't check development into `development`. Each user should branch of `development` and merge back completed changes. So far, so good. That is a pretty normal work flow, and makes sure that nothing gets into the relase branch that shouldn't be there. Now for your problem. Feck! `production` is being updated for the *next* release and so shouldn't be touched; \*snigger\*. Branch from the tag in `master` at the release. Create the new branch `hotfix-x`; where 'x' is the version as you may have moire than one hot fix. This is equivalent to `production` but is behind `development` and that's an important distinction. Normally changes are merged at the head from `development` to `production`, here we do it piecemeal. So let us begin... We will start with a dev change. First find the commit hash in the `development` branch. From `hotfix-x` do a cherry pick merge - `git cherry-pick `; one change done and dusted. Now we have the problem of the idiot having changed `production`. Slap the idiot then find the commit hash and *guess what you do next*? Cherry pick is your friend today. I personally would recommend merging from `development` to `hotfix-x` as much as you can. If there is a change that can only be applied to the older code then better branch from `hotfix-x` to `hotfix-name-the-change` Make the changes, unit test and merge back to `hotfix-x` then merge again to `development`. When everything is sorted out, kick the eejit and test from `hotfix-x` as you would from `production` If this is all on top of `ma
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Seems I am thinking along the same lines the as Mark above. If you (your company) are duplicating work, that is not a branching problem. It is a communication problem. I would assume that the bug fixes on dev are less urgent. Generally you could
**cherry-pick**the bug fixes from release -> dev. (In your particular case dev -> release. Still,**cherry-pick**is your friend. And try to keep bug-fix commits clean from feature commits.) Iam confused by the name "production / release branch". In many places, the release branch is short lived branch used for stabilization before a major release. I think in Google they even call it the "stabilization branch". After release you merge the stuff [=tested release related bug fixes] back to dev, and the release branch dies. Meanwhile fancy feature work can go on undisturbed on dev. Secrets of rapid release cycles, from the Google Chrome team[^] Your organization needs a reasonable view on the urgency of bug fixes on parallel branches. IMHO. :cool:... such stuff as dreams are made on
-
**Short answer:** Have you considered a commit by commit merge from dev to prod using [`git cherry-pick`](https://git-scm.com/docs/git-cherry-Git - pick)[^]? **Long answer:** As for the overall strategy, I'd say it is wrong! Whoever authorised changing the production branch should be taken out back and given a damned good explaination of how and when to change a branch! Let's start at the very beginning... `master` is the head revision of *released code*. No development should be checked in here, this is your latest and greatest release to the wild. `production` should be `master` plus anything `being deployed`. Again no development! The only commits are part of building the artifacts for release. Once built *and tested* it is merged back to `master` as the last step of the release. `development` is where all the changes being prepared for release go. And no, you can't check development into `development`. Each user should branch of `development` and merge back completed changes. So far, so good. That is a pretty normal work flow, and makes sure that nothing gets into the relase branch that shouldn't be there. Now for your problem. Feck! `production` is being updated for the *next* release and so shouldn't be touched; \*snigger\*. Branch from the tag in `master` at the release. Create the new branch `hotfix-x`; where 'x' is the version as you may have moire than one hot fix. This is equivalent to `production` but is behind `development` and that's an important distinction. Normally changes are merged at the head from `development` to `production`, here we do it piecemeal. So let us begin... We will start with a dev change. First find the commit hash in the `development` branch. From `hotfix-x` do a cherry pick merge - `git cherry-pick `; one change done and dusted. Now we have the problem of the idiot having changed `production`. Slap the idiot then find the commit hash and *guess what you do next*? Cherry pick is your friend today. I personally would recommend merging from `development` to `hotfix-x` as much as you can. If there is a change that can only be applied to the older code then better branch from `hotfix-x` to `hotfix-name-the-change` Make the changes, unit test and merge back to `hotfix-x` then merge again to `development`. When everything is sorted out, kick the eejit and test from `hotfix-x` as you would from `production` If this is all on top of `ma
+5 from me. I was about to suggest 'cherry-pick', then I saw this post. Cherry pick will be the best option here to pull a commit and push to a different branch. One important part here: whoever is doing this merge, should take care of the changes properly; else it may screw-up.
Vote up or Mark as Answered, if this information helped you.
Kind Regards - Kunal Chowdhury, Windows Platform Development MVP
Technical blog: http://www.kunal-chowdhury.com
-
I'd say that it was a bad idea to push changes directly onto the release branch if someone else was working on related code. That's going to cause merge conflicts. It happens but you should try to avoid it. You can use
git merge --strategy-option theirsto resolve the conflicts when you merge prioritizing any changes on the release branch, orgit merge --strategy-option oursto prioritize your (the dev) branch. If some of your fixes rely on the same code that was changed in the release branch though you might have issues and should consult with the team about overwriting the release changes with yours (assuming your fixes are equivalent to the release fixes). My 2 cents. EDIT: Also, is this an open-source project? I find it odd they would force only your code to be validated/checked while they're pushing changes directly to the release branch with no regards to other branches.:thumbsup::thumbsup:
-
**Short answer:** Have you considered a commit by commit merge from dev to prod using [`git cherry-pick`](https://git-scm.com/docs/git-cherry-Git - pick)[^]? **Long answer:** As for the overall strategy, I'd say it is wrong! Whoever authorised changing the production branch should be taken out back and given a damned good explaination of how and when to change a branch! Let's start at the very beginning... `master` is the head revision of *released code*. No development should be checked in here, this is your latest and greatest release to the wild. `production` should be `master` plus anything `being deployed`. Again no development! The only commits are part of building the artifacts for release. Once built *and tested* it is merged back to `master` as the last step of the release. `development` is where all the changes being prepared for release go. And no, you can't check development into `development`. Each user should branch of `development` and merge back completed changes. So far, so good. That is a pretty normal work flow, and makes sure that nothing gets into the relase branch that shouldn't be there. Now for your problem. Feck! `production` is being updated for the *next* release and so shouldn't be touched; \*snigger\*. Branch from the tag in `master` at the release. Create the new branch `hotfix-x`; where 'x' is the version as you may have moire than one hot fix. This is equivalent to `production` but is behind `development` and that's an important distinction. Normally changes are merged at the head from `development` to `production`, here we do it piecemeal. So let us begin... We will start with a dev change. First find the commit hash in the `development` branch. From `hotfix-x` do a cherry pick merge - `git cherry-pick `; one change done and dusted. Now we have the problem of the idiot having changed `production`. Slap the idiot then find the commit hash and *guess what you do next*? Cherry pick is your friend today. I personally would recommend merging from `development` to `hotfix-x` as much as you can. If there is a change that can only be applied to the older code then better branch from `hotfix-x` to `hotfix-name-the-change` Make the changes, unit test and merge back to `hotfix-x` then merge again to `development`. When everything is sorted out, kick the eejit and test from `hotfix-x` as you would from `production` If this is all on top of `ma
I will have to do some practice at home this holiday first, haha. But thanks man for the long tip.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Echoing the sentiment of most others here, but it seems that the approach in general is wrong and I can confirm that by having gone through something similar to this myself. I think there's enough technical content already giving you guidance on how to resolve this with Git, so I'll just add my bit about process. If you're in a slow release cycle approach of working then adopting something like GitFlow[^] could be beneficial but you need to make sure that the branch practices are followed, if you can enforce it with tooling then so much the better. We're using Visual Studio Team Services with Git and have adopted branch policies which prevent changes going on to certain branches unless by pull request with certain conditions met (e.g. reviewed, builds, tests pass etc...), I'm sure there's others way of doing the same with other tools. If you can release much more frequently then you can probably do away with most branches and simplify down to master and feature branches, but you need a rock solid release pipeline to make this work well, convince people that failing forward is a better approach to a rollout/rollback release process and have the organisational structure in place to support frequent and rapid releases. A lot of companies are still on their way to that or just aren't moving at all, so this is typically an aspiration to bring about other changes. It took a while for us to get a good branching strategy working and even now we still run into some issues which just seem insane to me (e.g. "why can't we have multiple people in two teams working on the same code file?"). But if you're willing to review current process and have team/business acceptance change it then you can get yourselves into much better position.
Eagles may soar, but weasels don't get sucked into jet engines
-
Echoing the sentiment of most others here, but it seems that the approach in general is wrong and I can confirm that by having gone through something similar to this myself. I think there's enough technical content already giving you guidance on how to resolve this with Git, so I'll just add my bit about process. If you're in a slow release cycle approach of working then adopting something like GitFlow[^] could be beneficial but you need to make sure that the branch practices are followed, if you can enforce it with tooling then so much the better. We're using Visual Studio Team Services with Git and have adopted branch policies which prevent changes going on to certain branches unless by pull request with certain conditions met (e.g. reviewed, builds, tests pass etc...), I'm sure there's others way of doing the same with other tools. If you can release much more frequently then you can probably do away with most branches and simplify down to master and feature branches, but you need a rock solid release pipeline to make this work well, convince people that failing forward is a better approach to a rollout/rollback release process and have the organisational structure in place to support frequent and rapid releases. A lot of companies are still on their way to that or just aren't moving at all, so this is typically an aspiration to bring about other changes. It took a while for us to get a good branching strategy working and even now we still run into some issues which just seem insane to me (e.g. "why can't we have multiple people in two teams working on the same code file?"). But if you're willing to review current process and have team/business acceptance change it then you can get yourselves into much better position.
Eagles may soar, but weasels don't get sucked into jet engines
thanks for your link, nicely illustrated! :) Gotta try!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Other posters have pointed out that generally fixes should be propagated forward from dev->test->release->production. However, I do recognize that sometimes a quick fix is done in production, for whatever reasons. This can happen a lot with scripting languages and undisciplined devs and support staff. In your scenario, I would have probably have tried to sync the production changes back into the appropriate branch and then apply fixes. If I was unsure of the outcome of the merge back from production then another branch could be easily made to test the merge out. If all else fails, don't forget that you can step out side of source control and manually apply back production changes if necessary. The git merge tools are usually very good, but sometimes things can get confusing. When you do attempt the merge back from production, make sure the dev that applied the changes is present if possible. Together verify the end result of the merge is the intended fix to production. In other words, don't guess at what the final merge product should be.
-
Nah it's for work. I had a long list of bug and feature to work on. Meanwhile the release / pilot product had issue (hey those were on Jira) and some independent fix were applied on that production build. For the simple reason they wouldn't want to deploy (untested / unvalidated) feature / bug fixes I was working on. So you have the silly version of that: Code has bug X, fix it in dev branch. But product has bug X too! Fix it in release branch (separately) since we don't want new feature (i.e. whole of dev branch) in prod branch. Makes only so far as I was also working on new and/or breaking feature (including database schema change) The whole process seems largely clunky to me.. Not sure ow to fix it though...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
For a case like this, we would fix X in the production branch and then merge back to dev. If X fix is so large that it could put production stability at risk, then create a production.X branch to do the work. merge production.X -> production -> dev. Once you create the next stable release candidate: production.X (if necessary) -> production -> candidate -> dev or for a new feature in candidate that is not in production candidate -> dev
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
There's your problem: "lots of fixes" ... which are part of a "dev" branch! Considering the overall instability of the app, I would be focusing on one high priority "fix" at a time; implement that; then move on to the next one. (Probably freezing all "new development" for the time being).
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I can't tell you how to fix things, but I can tell you how to make things better going forward: 0. Never do fixes on PROD. 1. When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT. 2. Do the fix on that branch. Check it in, issue PR, do review, etc. 3. Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge. 4. On a set schedule, merge DEV into PROD. 5. You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course. You can of course expand on the above to add in a QA or TEST branch area. I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run. YMMV and all that...
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I can't tell you how to fix things, but I can tell you how to make things better going forward:
- Never do fixes on PROD.
- When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT.
- Do the fix on that branch. Check it in, issue PR, do review, etc.
- Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge.
- On a set schedule, merge DEV into PROD.
- You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course.
You can of course expand on the above to add in a QA or TEST branch area.
I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run.
YMMV and all that...
-
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging. What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes. Meanwhile there are some issue on the production / release branch, which have been independently fixed. But some serious problem remains and I was asked to fix the prod branch. It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later.... How do you cope / handle such situation? Are we doing something wrong?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I can't tell you how to fix things, but I can tell you how to make things better going forward:
- Never do fixes on PROD.
- When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT.
- Do the fix on that branch. Check it in, issue PR, do review, etc.
- Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge.
- On a set schedule, merge DEV into PROD.
- You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course.
You can of course expand on the above to add in a QA or TEST branch area.
I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run.
YMMV and all that...