The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Ya know, when I saw that article a week or two ago, I wondered how long it would take someone here to bring it up.
".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
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?
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!
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.
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.”
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.
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.
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.