|
|
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
|
|
|
|
|
I only saw it on the newsletter but was not going to pass up the opportunity to bring it up again
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Fuchsia, really? My spider senses tell me there will be no end of twisting to that name.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
JSOP use the colour in one of his many articles, we have been twitting him for years about it.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I don't know, in many languages "ch" is pronounced "k". Conference talks about Fuchsia should be fun.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I think he likes the acronym as it's close to his
Android Open Source Project (AOSP),
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
