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.
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.
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.
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.
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.
Marc, this goes waaayyyyyy back, pretty sure very few will ghet this, not sure if John's memory will remember.
"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
Have you read any recent books like Code Complete?
Martin talks about things that I've never heard anyone else talk about that really expose what software development is like in real businesses. And he provides many ideas to alleviate the issues. Really well written too so it's a fast read.
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.
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