|
Battery.
Crazy - batty
about queen - ER.
Andy B
|
|
|
|
|
That's the one. Well done.
Slogans aren't solutions.
|
|
|
|
|
Why is Queen "ER"? just curioous. I thought it would be "Q".
"This new learning amazes me, Sir Bedivere. Explain to me again how sheep's bladders may be employed to prevent earthquakes"
|
|
|
|
|
Elizabeth Regina, it's on all the UK currency, postage stamps etc. but it might not be obvious to a non-uk person.
|
|
|
|
|
Actually it should be EIIR. No wonder I couldn't solve it. 
|
|
|
|
|
Slogans aren't solutions.
|
|
|
|
|
Sorry, yes, a tad parochial of me (we Brits tend to specialise in that).
It's a standard substitution in UK crosswords so I just used it without thinking. Sometimes I forgot that our queen is no longer the queen of the known Universe.
Slogans aren't solutions.
|
|
|
|
|
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?
|
|
|
|
|
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 theirs to resolve the conflicts when you merge prioritizing any changes on the release branch, or git merge --strategy-option ours to 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...
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
