- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I hate managers like that. Totally ignorant and instead of learning, just push their ignorance on everyone. At least the rest of the team knows better and ignores the dumbass.
Admin
Why have conflicts with every branch when you can have conflicts with every commit?
Admin
Having 20 years of experience means that when Bill started out, branching was most likely already a thing. I'm not really sure when the first VC with branching appeared, but I'd guess it was in the 1980s.
Admin
This sounds at best like someone who misunderstood the arguments against branch-heavy workflows, possibly due to reading opinion pieces that define "branch" differently to how git itself does, namely, as specifically that subset of branches which exist for long periods of time in projects where there's no requirement to maintain old versions.
Most of the arguments are strongest against those long-running "major project" branches, and secondarily against having a "new features" branch and one or more "fixes" branches... but that latter topology is probably imposed from outside anyway. And what's the betting this manager is basing it on CVS or SVN branches that are much more expensive than git?
Yes, you gotta rebase and fix conflicts, but that's always true, and the VCS-adjacent algorithms that don't have that, instead can't guarantee a lack of gibberish or eating one side's changes. So TRWTF might be structuring the codebase so that there's a lot of conflicts.
Admin
I spend way too much time on LinkedIn, and this is one of those annoying tech-bro flexes that frequently pops up. No branches! Trunk-based development! etc. Sure, go right ahead and handle your solo project that way, but don't ask me to join your team.
Admin
He should think of a branch merge as a single commit to the trunk and then get over it. As for falling out of sync, it likely is code for, "we don't think through our API design."
Admin
I hope he has the team put all their code in the same file. Multiple files are just a point to have confusion, can't put code in the wrong file if you have only one.
Oh, and it worked differently than now, but sccs had branches. In 1975.
Admin
I have some sympathy for the boss if that view was limited to feature branches that were both long lived and actively developed. But for a reasonable size unit of work not ready for merging to main or under review?!
Admin
Indika then relaxed at her desk by the window; she could see the squirrels, and they were merry, but then, they switched from PRs to an Excel file... NB: It can always get worse, so don't complain about "We just don't tell Bill."
Admin
I hate to say it, but he's not wrong - when everyone knows what they're doing. Some of the biggest minds of modern software development (Kent Beck, Martin Fowler, Dave Farley, Kevin Henney and more), many of whom coined the terms we often (mis)use today, work this way. You can find extensive talks and interviews from them on the Modern Software Engineering channel on YouTube (and elsewhere). The problem is we get folks like Bill that just hear "no branches or PRs is better", which they like because they hate doing code reviews, but they ignore the tests, infrastructure, and team dynamics that are required to make it functional, let alone effective. Here's a link to just one such snippet where Dave Farley and Jez Humble, who literally wrote the book Continuous Delivery (2010), talk about it.
I think the biggest struggle for them to understand is not all of us are blessed with expert developers that have been doing proper CI/CD for decades, know how to commuincate, write proper and effective tests, isolate and decouple code, etc. Training the team and getting the code to the point we can do proper CI/CD is a massive lift; if your whole team and/or management isn't fully on-board, it's not likely to ever succeed. Even if they all are, it takes more than hopes and dreams to get there, and for many that's a long and tough path to get through, especially if management won't let you bring in anyone to help. I know after many decades I'm still tilting at that same windmill myself Time to go look over another PR that I'm sure contains zero tests.
Admin
This seems to be more of a fundamental misunderstanding of git and GitHub workflow than a valid criticism of trunk-based-development. Sane trunk based development allows branches... just the CI system only CI's the trunk. Feel free to have a branch for your work-in-progress and use the code review process to guide it back to the trunk.
We don't use git (SubVersion here), and although we do trunk-based-development, we have branches. Due to our technology stack, it works better that we have one long-lived Dev branch instead of per-work-item branches. You can bet that if we used git, we'd be doing per-work-item branches, because that's how the tooling is designed to work.
Admin
I did some work for a customer that used git. They had lots of branches. Lots of branches that had been around for years, without being merged.
My reaction to that wasn't "don't use branches" - it was "you're using branches wrong, and here's what you should be doing instead, and why." I'm not entirely sure that they understood it or made significant changes... but I tried.
Certainly if I were faced with the attitude espoused by Bill, I'd be strongly inclined to start looking for another job. When the team is working around the manager, it's a bad sign for the long term health of the project.
Admin
Maybe Bill started out with Visual SourceSafe, which would explain his attempt to minimise any interaction with the VCS to the maximum extent possible.
Admin
20 years ago, source code control was a bit more rudimentary - CVS or SVN were the leaders. If you were fancy, you used Perforce. For all of these, sadly, branching was complex and merges even more so. I still remember creating a branch in P4 and having it take the better part of an hour just to create. Merging tools were around, but fickle.
BitKeeper was really the thing that changed things where you could clone repositories and then push all your changes back at once. A rudimentary form of branching really, but it did a reasonable job if you kept your pushes and pulls straight.
Git pretty much transformed workflows by basically making branching the standard operation - you'd clone, create a branch, do your work, then merge it back. And much of git's workflows involve navigating and pushing and pulling between branches. it's something you don't quite get used to - which is why git still has a standard non-branch mode of commiting and pushing to main, but really encourages you to create branches as often as you want. Branching is cheap - it's basically creating a new head pointer file in the refs/branches directory that points to the current commit. Takes basically zero time since a branch is basically a hardlink to the current head commit.
This also means most of the git magic is in merging - and git has some very powerful merging tools able to handle line number changes when files diverge.
It's powerful enough that even when branches diverge over years, they can still be merged together with some manual fixing, but most of the merges being done automatically. (Of course, it's best practice is not let things get so badly and to periodically merge to for from main). But it's entirely possible because I did it over the period of several days.
Admin
My experience when going from svn to git was how much more difficult the merge/rebase was and how much worse the conflict resolver is in git compared to what it is in more recent version of svn.
Admin
To be fair there is the practice of trunk-based development. Its basically that everybody pushes to main, provided that the changes in each push have ways to turn on or off. If you really have a small team, this is actually a good practice. Combine with automated tests (that you actually trust!), you can release whenever. Write a CI tag pipeline that deploys to prod. If you do stuff like game development, which usually involves tons of files that get easily borked from merges, this actually reduces your time spent fighting the version control system quite a bit.
That being said, if you still spend time fighting merges every time you pull, you need to break the unmergeable files into smaller pieces. That stops people from stomping on each others work.
I'm guessing in this case the manager wasn't trying to do what I've described.
Admin
well... i joined the DBA team in a rather big company... they use MySql as database... but no foreign keys to see in the whole DB... he was not fond of them apparently...upon asking what the R in RDBMS stood for, he got mad and never said a word to me again... lucky for me he was retiring after a few months
Admin
To put on my "that guy" hat, the R in RDBMS stands for "relational", which refers to a relation, which is a formal definition of a table for relational algebra. It actually doesn't reference relationships. Codd did lay out the idea of joins, which weren't managed via enforced relationships in his initial model, but were just fields shared between different relations which allowed the relations to be connected.
But yeah, good riddance to that DBA.
Admin
I worked for a customer that used Subversion. In SVN, branches are only a naming convention: if you want them, you create top-level directories typically called trunk, tags and branches, and then switch your working copy to whatever location you need to work on, e.g. branches/feat-foo. This customer had an additional level. Repo root would have v1, v2, v3... and each of them had their own trunk, tags and branches... except that only trunk had contents. Turns out they worked this way:
Admin
And lo! They raised in the sands a pillar of granite. And upon it was carved a pattern of holes.
And they called it the diff. And all copied from it.
Admin
I worked at Halliburton for several years. The group I was in also prohibited branches. It wasn't the devs that prohibited it, it was the QA team that prohibited it. Partly because once in the history of the source code a merge went bad (it was TFS so there is that). The other part was because the QA team realized devs could keep working on new features BEFORE THEY FINISHED TESTING THE CURRENT SPRINT DELIVERABLES!!!
This meant that by the time they were done testing the current sprint, there would be a backlog of testing to do and they could not have that. It would mean they were a bottleneck in the release flow.
There was a lot of other abjectly stupid shenanigans they'd pull mostly centered around this perpetually very angry lady that seemed to spend both work and personal time plotting to grief other people. It was about as stupid as you can imagine.
Admin
I would argue that it was PVCS which showed up in 1985. SCCS and RCS sort of did branching too though.
And I'm not that Bill.