|
I use Git at home but at work we use SVN and for a lot of the work we cut ourselves a new branch for each new 'user story'(an abuse of the English language).
Once we have finished our work and it has been code reviewed and passed code review we then merge the changes into trunk.
At that point we sometimes hit merge conflicts and on rare occasions it does become a bit of a merge hell.
If you are merging your branch every morning and you are getting lots of merge conflicts that would suggest that something is not quite right and I can think of a few reasons for this occurring:
(1) You are not cutting a new branch each time you are staring new work.
(2) The code base is poorly written with methods that are hundreds of lines long and are shared by many parts of the system leading to developers working on the same section of code at the same time.
(3) Someone else is not cutting a new branch and is introducing a whole load of old code which you are then having to correct with your commits.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
"'user story'(an abuse of the English language)."  
cleaning screen now...
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
It is one way to do it. Feature branches are common but... some projects are in a too much embrional state to be easily sectioned out in features (a lot of code, common base to be built etcetera), others have a bad legacy codebase that requires frequent adjustments to many parts of the code.
Also if the team members jump around between features (maybe because the project is badly managed, maybe because the team is too small for the amount of job, or they are just messy developers used to such methods or some/most team members have other projects and other roles that may take precedence over the developing work at any time) this ensures a low, fixed number of branches.
It might also be better suited to R&D projects since R&D is mostly exploration of possibilities, with no clear cut features to be implemented and considered done.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
We use topic branches, where 'topic' can be anything from a typo fix to a full blown new feature, the later case being usually split up into separate parts to avoid huge pull requests and make reviewing easier.
I only have a signature in order to let @DalekDave follow my posts.
|
|
|
|
|
We all commit to a single master branch, except for the case of big new features where it would be developed in a feature branch. With 150 developers working on the same code base, it wouldn't be feasible to have each one use their own personal branch and create a bottleneck for those tasked with pushing the changes across to master.
Another reason we use a single branch is that it helps with integration testing. If we are all pulling up to tip and developing on the current state of the software, we are much more likely to find bugs sooner.
|
|
|
|
|
It's a very common practice for features to be developed in their own branch, often with a single developer working on each feature.
This process ensures incomplete code isn't released to production and allows for peer review through the pull request process.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|
|
Never heard of each developer having a separate branch.
If each is working on separate areas, I expect that works fine. But if there's overlap? Welcome to merge hell.
We do some local commits when working on an item that requires more than a few days of effort, then merge the local commit back into the central repository when unit testing is passed. In general we try to work on small pieces than can be committed to central after passing unit testing. Frequent merges make the eventual merge conflicts easier to deal with.
|
|
|
|
|
Super Lloyd wrote: But since 2 weeks of work from an other developer can drop anytime
This is probably the biggest issue. Having that much work without merging is bad joojoo. Unless people are working on completely separate sections of the project that much work is likely to always cause merge conflicts.
Feature branches are one way to go if it's possible.
It would be important to me to find a way to section off work so it can be merged in as it's completed if there's no dev branch. Like getting backend code finished and checked in as a "slice" before doing the front end and/or controller part. Any way to get functional chunks of code in without taking 2 weeks to put in huge chunks.
That sounds bad man.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
I don't understand how everyone working off of the main branch would even work, that seems ridiculous to me. Topic branches are the standard way of doing things and IMO the best way of doing things.
Let's say you and another colleague are tasked with adding a feature, say adding a new window to an app. He starts to work on the view model, and you work on the UI. He finishes a portion of the view model and you want to start testing your UI with it while he finishes the rest. How the heck would you accommodate this without a "feature/new window" branch that you can both push to and pull from? You shouldn't be merging a half-finished view model into the main branch because now everyone else will have a half finished view model when they pull!
Or let's say you get sick and need to take a few days off and someone else has to finish up your work...that means:
a) they can't because you haven't been pushing code from your local repo to a feature branch in the company repo at the end of each day, or
b) he can because you've been pushing incomplete buggy code to the main branch which gets pulled any time anyone pulls the main repo, so now everyone has your half finished code in their code base and has to deal with whatever problems that may cause
The way you were using git before and the issues you are having with it now is clearly an organization and management problem. If you guys had someone good at managing distributed projects directing things it would be a world of a difference. I would suggest hiring a consultant who is good at this to help you guys develop a better process.
Everyone should be committing many times a day to their local repo, and pushing to the company repo at the end of each day or when they finish something and want to share progress with someone else working on the topic. If the main branch gets some significant updates then you can merge those with the topic branch regularly so that when you finally finish the topic 2 weeks after you started you don't have 2 weeks of merge conflicts to fix all at once, rather you only have to deal with any issues from the last merge you did a day or two ago.
Responsibility should be managed such that people working on different topics are extremely unlikely to change the same files.
Git is a beautiful thing if used properly, but that requires good management with well thought out processes, discipline on the dev team and well organized code with good separation of concerns.
|
|
|
|
|
Super Lloyd wrote: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
It depends on whether you want to resolve merge conflicts between two branches or merge conflicts between two commits. The best advice I can give you to avoid merge conflicts is to either work alone or re-review your architecture (unlikely to happen).
I have worked in both cases, and working on separate branch feels better, since no merge requests are done at the end of the workday and finishing a bug/feature is unlikely to align with the workday schedule. As a result, not everything that goes into the central repository is complete (and tested). So if it is untested, it is better to be on its own branch.
|
|
|
|
|
I guess that is why I could never get my head around "version control" if one was a one man band.
A typical "project" includes images, pdf's, text files, utilities, etc. Accumulating over time.
I zip everything every day or 2 and create 10 or more generations. Covered most brain fogs.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
All features should be on a different branch. If you are getting lots of conflicts then I have to wonder about your project architecture. Are you using something like PrismLibrary to separate out your modules?
|
|
|
|
|
Plan your work in small units (1 day) if possible. Except where specifically required squash the history of your local branch (git rebase -i) down to a single commit. You'll simplify resolution of merge conflicts, keep your features as atomic units, and keep your history clean of junk comments. Your workflow should look something like: pull master -> branch -> commit -> squash -> rebase -> push pull request -> review -> ff merge -> repeat.
Commit -> squash -> rebase gets repeated as a whole or individually as needed.
|
|
|
|
|
Markdown Tables generator - TablesGenerator.com
Pasted some Excel data into it, clicked generate, clicked copy to clipboard, pasted into BitBucket wiki, done. Took less time than writing this post!
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: Markdown Tables generator - TablesGenerator.com
Hey @John-Simmons-outlaw-programmer, look they do latex as well, not too sure if that also covers full body suits.
Marc, this goes waaayyyyyy back, pretty sure very few will ghet this, not sure if John's memory will remember.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
I can't get to the page from work. My Latex Appendage Suit hasn't seen much action of late. I don't even think I'm flexible enough anymore to get into it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
Nice. You should probably post this in the Free Tools forum[^], so it's less likely to get lost. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You should probably post this in the Free Tools forum, so it's less likely to get lost.
I think I lost the brain cells that knew about that forum. 
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Thank you, Marc! 
|
|
|
|
|
|
raddevus wrote: I've recently read one that is close and is really fantastic
Hah, chapter 25 has a section called Hunt the Wumpus! Awesome, I wonder how many people nowadays know about that reference. I'll have to get the book just to read that section! Gregory Yob was actually quite a mentor for me in my late teens -- we hung out together quite a lot and he actually rented a room from me for a while in San Diego.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: Hah, chapter 25 has a section called Hunt the Wumpus! Awesome
Yeah, it's a great chapter. The whole book is honestly filled with that kind of great stuff.
It's like sitting down with Martin and just getting to listen to him and his experiences but hearing how to apply solutions too.
Marc Clifton wrote: Gregory Yob was actually quite a mentor for me in my late teens
That's very cool!
|
|
|
|
|
Marc Clifton wrote: ...I wonder how many people nowadays know about that reference.
Probably about as many that know of Windows' Burgermaster memory segment.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
David Crow wrote: know of Windows' Burgermaster memory segment
That's a good one. I remember reading about that in a book when I was learning about Win 3.x API programming. Was the story in Petzold's book? I think so, but can't remember.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
