|
Current Story:
Where I am working now we are using GIT, like many company before.
But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer.
Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days....
What I wonder:
is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
|
|
|
|
|
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?
In my experience, that's extremely uncommon.
I see it as being wasteful, both in the effort required to maintain it and system resources.
Working copies isolate your scratch work from the core code; branches are for when a new or different version is needed.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
That is what we do here in a team of 5, most of the time. Everything goes into it's own feature branch, which is merged back into the develop branch later. And yes, we do get merge conflicts.
|
|
|
|
|
Jacquers wrote: Everything goes into it's own feature branch
That's a lot more common (and useful) than the "branch per user" thing.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Well, it's usually a feature per developer, so it amounts to the same in this case.
|
|
|
|
|
Sure, but "private ownership" of the branch doesn't exist -- if the dev moves on to a different feature/product, he'll work on the branch for that, and someone else will take over the branch he'd been working on.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Yes.
And if two or more devs work on a feature they will work on the same branch.
|
|
|
|
|
In Git, branches are a part of your everyday development process.
Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes.
This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future's history before merging it into the main branch.
-BitBucket. 
But for smaller changes, that we are very confident of what we are doing, I don't think branching out & merging back is needed?
Full Reset
modified 10-Jan-19 3:15am.
|
|
|
|
|
Rule 1: you never really know what you are doing, so we will come to your office and kill you if you edit directly on the production branch
Rule 2: if you think you know what you are doing, please refer to Rule 1.
|
|
|
|
|
rofl . Okay. Point noted. 
Full Reset
|
|
|
|
|
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?
Probably in a team of 4-5 people.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
