|
Don't try to do it from your desk. Talk to people.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Short answer:
Have you considered a commit by commit merge from dev to prod using git cherry-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 <hash>; 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 master then it should be merged back, see above, when it is released.
veni bibi saltavi
|
|
|
|
|
+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
|
|
|
|
|
I will have to do some practice at home this holiday first, haha.
But thanks man for the long tip.
|
|
|
|
|
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. 
... such stuff as dreams are made on
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
Imagine if you went to France and your name was Gemma Pell [^]
Not my joke, I hasten to add, but it did make me laugh.
|
|
|
|
|
Imagine if you went to Germany and your name was Wilma Bumsen.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
A friend of mine helping at a restaurant discovered once the name Wilma von Hinten on a marriage guest list.
|
|
|
|
|
Perfect.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
This reminds me of my first few years in Canada not getting the Frenglish puns.
Whoosh! There went another one over my head...
(I'm better now. Osmosis is a wonderful thing)
cheers
Chris Maunder
|
|
|
|
|
Osmosis?
I think a better analogy would "decay is inevitable", or perhaps "things will be better in the next life", or, "I'd rather have beeen kidnapped by aliens and probed".
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Imagine if you went to America and your name was Seymore Butts...
Jeremy Falcon
|
|
|
|
|
Or Dick Hertz.
Or Phuk Yu.
Or Ivanna Svahlo
Or... ok I'll stop 
|
|
|
|
|
Old urban myth: Pugwash (really really really old animated series),
the hands on the ship were 'Master Bates' deckhand 'Seaman Stains' and 'Roger the cabin boy'
and then there's the since adopted meanings for Pugwash[^]
Kids today have nothing on the fun we had way back then, sadly some bleeding heart moron (oops) invented: 'PC.' (No not the IBM thing)
Can't even be a proper grumpy old man with these *&^* newfangled rules.
|
|
|
|
|
I clicked that Pugwash link and now I regret everything  Rule 34[^] I suppose.
|
|
|
|
|
Ah, for duck's sake: You made me go to Urban Dictionary, and I just HAD to check out the "Trending now" links.
I wish I hadn't, because now I know what a "Dog in a bath tub" is, and I really wish I hadn't seen that! How is that even remotely possible??? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
|
Why am I not the least bit surprised you'd have ready reference to that type of information?
Well - as long as I've got your attention, do you also have a link to the site giving installation instructions for these items?
And if you do, that wouldn't surprise me, either.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
A friend of mine used to be a nurse in the maternity ward of a London hospital, and they "share" that kind of info around. Particularly if the gentleman (for it is usually thus) is currently in A&E, standing in the corner and buzzing gently... 
The worst patient she met was a very young lady who was undecided whether to have an abortion or not: when she met her in late term she brightly said "So I see you decided to have the baby then?" only to be told "Nah. I aborted it meself."
While visions of knitting needles, coat hangers, and other unpleasantnesses marched resolutely across her mind, the patient pulled up her jumper to reveal a band-aid across her belly button with the triumphal words "I suffocated 'im!" 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: The worst patient she met was a very young AND BLOND lady who was undecided whether to have an abortion or not: when she met her in late term she brightly said "So I see you decided to have the baby then?" only to be told "Nah. I aborted it meself."While visions of knitting needles, coat hangers, and other unpleasantnesses marched resolutely across her mind, the patient pulled up her jumper to reveal a band-aid across her belly button with the triumphal words "I suffocated 'im!"
FTFY!
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
lopati: loaming wrote: then, sadly some bleeding heart moron (oops) invented: 'PC.'
Sadly, the blame is more easily and correctly place of the religious right . . . those folks who brought (and still try to bring) censorship tall all they perceive as immoral.
You know - the folks that see pornographic images in Disney Cartoons[^].
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
(SFW, probably)