If you do all your development in the MASTER branch, do not call yourself a git "Guru".

Call yourself a "risk taker" hahaha

I think it really depends, most of the time I dont need an new branch. Only by huge changes. But yeah I don't call myself a dev guru.

@rEaL-jAsE another account.... And where is salt?

No, I am no git guru, I am a git master...

Im a git noob, looking to git good

how could ANYBODY possibly be a guru at anything in our field (see JS libraries for ex)

when I read "guru" I immediately think of someone with absolutely no self-reflection

Actually, according to the puppet labs state of DevOps report 2014, it’s actually better to only work on master. It forces you to keep changes small and if anyone breaks anything, no new code till the build is good again. As opposed to feature branches where teams wait till last minute to merge and run it tons of issues right before release

This was inspired by the Toyota production system. If a line worker runs into an issue, they are empowered to shit down the entire line and it’s all hands on deck to solve the problem. That’s how they ensure quality

@windlessuser thank you!

@windlessuser You could also address that issue by taking the habit of rebasing your feature branch every day. Git-flow helps a lot.

@Masta the main problem they found with git flow is that you need the discipline to merge the feature branches in daily. What unfortunately happens in reality is that it’s put off till the end of the sprint and there tends to be a scramble to fix all the conflicts and QA gets it way too late. Teams that work directly off master apparently deploy more often with less defects. Check out the report, it’s free

@windlessuser Thanks, I'll look into this. But on my first opinion the "it needs discipline" argument is not strong enough: after all you still need discipline to produce quality code, to not push the wrong code on the wrong depot, and so on. It's just one habit amongst many others. And without more information about that, doing everything on master seems like risky... Unless you add... well, some discipline here too.
But you still made me curious so I will read about it ^^

@Masta Exactly! You just illustrated why you work on master. One rule: if the build breaks, focus on getting it buildable again, no new features till then. By design, this forces everyone to push smaller commits and everyone is mindful of who is merging what. This also creates tons of confidence that the code will be mostly stable and everyone has up to date code

@windlessuser But how does that applies to very large teams ? If you have 15+ devs on a same project, then they all stop their current work to focus on that single issue introduced by only one of them ? Or only 2-3 of them are working on solving problems while the others are waiting it's solved ?

@windlessuser Found that report you mentioned, sadly I think I was expecting more detailed information. Reading this I feel like the essential part is merging small commits in master very often. So I think that goal still could be achieved with git flow, just by cutting tasks in smaller features. That way you still have feature branches (and the pro/cons coming with it: you'll need to remember about rebasing it regularly but it will be harder to mess with history by accident), but these features branches are the smallest possible so you don't keep working on the same for too long.

Finally I think like this is much more a matter of how you can break your features list in smaller features, than using features branches or not.

Call it dev branch set as default and happy merging all feature branches..

@Masta In regards to team size, Google found that ideally, a team should be no more that what could be fed by 2 large pizzas. That is, 5 to max 7 people - without an SRE who is ususally shared by other teams.

So, for a 15+ company, it could very reasoably be working on 2-3 different products.

get everyone on slack -or what ever- and discuss the merge issues that come up. You'll solve problems really fast.

Oh I don't haha.

Don't call myself a git guru 😅

@rEaL-jAsE sad life

fake guru

@Gobbas That cracked me up!
Good one. 😁

I create separate branches only for features that will take time and its low priority. Most of the work goes on Master. If i worked with 50 colleagues maybe it will be better to have a lot of branches, but in small teams its just waste of time.

Of course why do you guys need even git? Just upload directly on production server! Why waist time on using git or if you already code guru... why write test and spend time for fixing? You can code without any bugs 😊