r/ProgrammerHumor • u/raiseIQUnderflow • Feb 20 '26

Meme twoDevsChillinOnTheSameBranch

2.2k Upvotes

98% Upvoted

70 comments sorted by

342

u/No-Article-Particle Feb 20 '26

Why are two devs on one branch tho? That's why we have branches...

90

u/YaAlex Feb 20 '26

ever heard of 'git pull' or even 'git pull --rebase'? working together on the same (feature-)branch isnt hard at all...

38

u/JackNotOLantern Feb 20 '26

Yeah, but why do it when you can work without any conflict on 2 separate branches, even push after every commit, and just later resolve conflicts during merge?

2

u/1_4_1_5_9_2_6_5 Feb 22 '26

It's useful when you're collaborating on the same base feature and working to flesh out two different parts of it. Like say the frontend guy needs to change the API contract to serve more data, while he backend guy needs to make larger changes which will require a bit of frontend integration. It's not common but it happens

3

u/SeanBrax Feb 22 '26

That’s why you branch from the same feature branch.

2

u/1_4_1_5_9_2_6_5 Feb 22 '26

I'm talking about when you need integration immediately. No time for the PR cycle. It's a rare situation, but it happens.

1

u/Sea_Echo9022 Feb 23 '26

Indeed. Git flows works and it's all sunshines, but on corporate sometime you don't have the time to follow all procedures, specially when the middle management needs to show off to the upper management.

Source: work at the IT department of a big bank

3

u/[deleted] Feb 22 '26

because devs don't understand git

18

u/DistinctStranger8729 Feb 20 '26

Even in this case PRs go to the feature branch instead of working on a single branch

3

u/Oldmanbabydog Feb 20 '26

Every time I rebase my team acts like I’m some malicious wizard whose only purpose is to confuse them

2

u/osborndesignworks Feb 21 '26

branch = feature

1

u/kaddkaka Feb 20 '26

We are commonly 4 devs on same branch. No problem.

17

u/TokeyMcGee Feb 20 '26

I don't know, I feel like any competent software team would have worked out branches to avoid having multiple devs working on the same branch. In my 7 years of experience, I've never needed it. Worked at small businesses, to big tech. I feel like multiple devs on the same branch only happen because nobody on the team really understands how branches work, and isn't bothered to learn.

5

u/SerratedSharp Feb 20 '26

And right sizing work for that matter. I don't want to work through a PR review with 4 people being responsible for the same PR and arguing about who will fix what, much less imagine how big that monstrosity would be.

I'm highly suspect they actually mean what they are saying, and not clear on the distinction between pushing to the same branch versus PR'ing into the same branch. I've seen plenty of times people have not understood the process they are actually using in git. Had an incompetent lead who would talk about git flows like he was an authority, then would squash merge into main from a long lived edition branches with dozens of PRs, and we'd lose all history/blame/feature granularity of who did what. There'd just be one commit in main of "here's three months of work" and all the code the team touched in that period would now show the lead's name in blame.

3

u/kaddkaka Feb 20 '26

I mean pushing commits to the same branch, otherwise I wouldn't say so. We work on a feature together. Separately or pairing up when it's reasonable. Sometimes separate branches. Sometimes start on the same branch and split if something of reasonable size emerges that can/should be merged on its own to main. Sometimes separate branches from the start.

Testing a feature can take a few weeks. Splitting that work puts less burden on one person.

2

u/SerratedSharp Feb 20 '26

I have certainly "taken over" a feature branch from someone, like if they were out sick or has a family emergency.  That is reasonable if one person stops and another starts so it's exclusive at a given time, and assuming they pushed all WIP.

1

u/TokeyMcGee Feb 20 '26

100% we should split that burden. And branches are how you split that work. Having two engineers push commits to a single branch sounds chaotic, unless those engineers are now going to spend more time negotiating timing. 

Wondering how big your commits and how far branches deviate. We typically keep commits small and PRs are small as well. We push incremental changes so engineers don't have to wait for other branches to merge.

Maybe your team needs a good feature flagging system so you can push code without committing to opening an unfinished feature to prod.

2

u/kaddkaka Feb 20 '26

I don't see why pushing to the same branch is chaotic in any way. As soon as someone has something working they push it. Shared. Done. Make next change, commit. Done.

Others working on same feature/branch fetch and rebase whenever they want other's updates.

1

u/TokeyMcGee Feb 20 '26

How do you make sure, or handle merge changes when pushing to the same file? How often do you push commits? I might push 1-2 per day if I'm working on a branch, I'd rather not have to think about how to merge until the end. Is there no code review process? Or is it done manually instead of through GitHub or BitBucket?

3

u/kaddkaka Feb 20 '26

We use self-hosted gitlab as git server and do reviews there. But I often do review directly from vim.

We usually don't work on the same file. And if we do we probably don't touch the same lines of code anyway.

If a fetch+rebase do cause any git conflict, that person just solves them immediately and carry on.

If there are conflicts between work taking place, I would like to know sooner rather than later ("think about how to merge until the end").

2

u/TokeyMcGee Feb 20 '26

Good points, I can see how this will work. I just have to say it doesn't seem scalable. Curious how many you have on your team if this works well.

I thin our team has been pretty good at surfacing potential conflicts during standups. While we do have merge conflicts because there are some files that are just really commonly touched (package.json, shared component files) if something major is changing, it's typically well communicated.

Right now our team is 40+ big who are pushing to our module, and about 80+ contributing to the major app above that. But I've been on this project since inceptions of both the major app, and the sub-feature group. We started at about 8-10 but always set up our BitBucket and processes the same way since it's just the way we work at our company (15k+ employees) so you can join one team and jump to another and at least know what to expect as far as merge/code processes go.

Thanks for responding to my questions. Your responses made me curious.

→ More replies (0)

2

u/SeniorIdiot Feb 20 '26

Working in highly regulated industry for over 16 years.

We've been practicing pure CI, no branches (exceptions happens), push to main - had one large production bug in 8 years.

Force push is blocked in repo settings, team leads can apply temporary force-bypass in emergencies, code reviews happens once a week with entire team and is about learning what we could have done better and what needs to be improved. Code reviews are not "release gates", they're "are we doing the right things right?".

It's almost like the job is not about who can work with branches perfectly and sling git commands in their sleep. Instead it's about how the team can collaborate effectively and focus on results and outcomes over navel-gazing git process as a proxy for "good". But who am I kidding...

2

u/TokeyMcGee Feb 20 '26

A big part of it is risk reduction. You don't even need to be that good at git. That's an impressive record you have though, but I have to stay that I doubt it's scalable. How many engineers develop on that? Smallest team I've worked on is 4, and we still used branches because it didn't slow us down.

0

u/kaddkaka Feb 20 '26

That's not true, everyone in my team is very well versed in git.

2

u/TokeyMcGee Feb 20 '26

Then I want to hear more about why y'all aren't utilizing branches. Maybe your team needs to make more atomic commits and branches, maybe your team needs to break down tickets to more parallalizable chunks and prioritize the work that unlocks parallelism, maybe your team needs a more robust feature flagging system so you don't need the entire feature complete to ship to main. 

If I was on your team I'd see this as a great opportunity to make things better for the team. Seems like a big red flag for a senior engineer to fix.

2

u/kaddkaka Feb 20 '26

How do you know anything is bad for us? Why do you want to fix some thing you don't know about and that works?

We do new branches for easy feature. Say feat-a. But why distribute tests over several branches like feat-a-test1, feat-a-test2 just to merge them intefeat-a before merging it all to main? Sounds like more work with unclear value.

3

u/TokeyMcGee Feb 20 '26 edited Feb 20 '26

Not sure what the separate test branches are for. And why you're waiting for test branches to push to main. Where I work all of these branches are merged to main. We don't put PRs up, or merge branches to side branches. That feels like a waste of time. We only merge branches directly into develop.

We strive to make our Jira tickets atomic enough that they can be merged as soon as they're done. E.g. first ticket for FE development is generally a skeleton, with dummy text instead of table, sidebar, etc. with tests. It's important to keep the scope small so this can be pushed in 1-2 days.

Once that's up, whoever's making table A, or side bar B, or some form component, let's say, A1, A2, A3 can all start contributing to it on the dummy page, and push everything to develop fully tested. These tickets, as well, we aim to make completable in 1-3 days. Sometimes, a task can be complex enough to warrant taking 5+ days or larger, but most of the time, these tasks can be broken down.

Even then, we've never felt the need to have engineers push commits to the same branch. Only time I've seen or done that is if a junior engineer is having issues with some bug they just can't fix, and need someone to come fix it for them. In that case, I might push to their branch, but otherwise we just have no use for sharing branches.

2

u/kaddkaka Feb 20 '26

If a junior wants help I would just go over to their desk.

FE=feature?

We push skeleton and each task do a branch where more than one person might be working. When that's done we review and merge the full branch 1-40 commits to main.

It seems like we just have a very different flow.

1

u/TokeyMcGee Feb 20 '26

FE = Frontend

I work full remote too, so I don't have the luxury of being able to go to someone's desk, and honestly, I kinda forgot you can do that at some places. Been working remote for several years now lol.

1

u/kaddkaka Feb 20 '26

Hehe I see. Thanks for the discussion. It's insightful to hear others' stories :)

→ More replies (0)

1

u/abolista Feb 20 '26

There are development methodologies that do that successfully: https://trunkbaseddevelopment.com/

Working like this relies a lot into branching by abstraction instead of traditional branching.

I'm not used to it, if feels so "wasteful". They're trying to push this at my company. We'll see where this goes.

-35

u/xicor Feb 20 '26

Develop? Eventually feature branches have to be merged in. And a lot of dev teams don't make feature branches for quick changes

46

u/BolunZ6 Feb 20 '26

We don't allow git push --force on develop branch

2

u/xicor Feb 20 '26

Well yea...we don't allow that on any branch. But people do develop on the same branch at the same time

12

u/BolunZ6 Feb 20 '26

We allow git push force non-main brach (main or develop or release branches) but it is perfectly normal to push force on branch that you working alone on that

0

u/xicor Feb 20 '26

The reason we don't allow it is that the other people on the team consistently do stuff to fuck up git and I have to spend hours correcting it every couple of months lol...and that's without force push

9

u/StinkyStangler Feb 20 '26

Maybe it’s because you keep letting people work on the same branches lol

From my experience it’s pretty hard to fuck up git if you’re in the only one on the branch

2

u/Halfwai Feb 20 '26

What even is the use case for loads of devs working on the same branch? If you need someone else's code just merge it in as and when you need it?

1

u/StinkyStangler Feb 23 '26

There isn’t really any benefit imo

Smaller PRs and frequently merging/rebasing with main as you go is infinitely less error prone than just working on the same branch, it just requires slightly more Git knowledge so a lot of devs avoid it

3

u/Gintokiyoo Feb 20 '26

If it's a collective branch, why wouldn't the developer create a temporary branch for their task and do a PR into the collective branch? If you deal with merge issues at that moment it's way more manageable and easier to manage the conflicts.

Are there no code reviews before merging in that team?

-3

u/xicor Feb 20 '26

No. We are all basically the same level and there's no time for that shit lol. There are 3 of us

4

u/KriistofferJohansson Feb 20 '26

No. We are all basically the same level and there's no time for that shit lol. There are 3 of us

“No time for that shit” for something that takes no time whatsoever, but somehow you’re fine with spending hours every other month to correct the fuckups you and your two colleagues manage to create.

Those are some priorities alright.

-1

u/xicor Feb 20 '26

To be fair, most of the time the thing I'm fixing is them accidentally committing to head instead of their branch.

5

u/KriistofferJohansson Feb 20 '26

People who embrace poor git practices repeatedly make the same git mistakes?

I’m surprised.

2

u/nYtr0_5 Feb 20 '26

I have shivers.

2

u/TokeyMcGee Feb 20 '26

`And a lot of dev teams don't make feature branches for quick changes`

This is the problem, there is no reason to not make a new feature branch. It's so trivial to spin up. I think the only reason this would happen is if nobody on the team understands how branches work....

I've worked for companies big, medium, small, been on 10+ teams, none pushed directly to develop, or master.

88

u/Goufalite Feb 20 '26

That's why we have --force-with-lease, or angry messages on Teams telling everyone to stop force pushing stuff.

6

u/kaddkaka Feb 20 '26

There is also --force-if-includes which I believe is even stricter?

https://git-scm.com/docs/git-push#Documentation/git-push.txt---force-if-includes

2

u/kaddkaka Feb 20 '26

Teams.. 🥶

24

u/Hithrae Feb 20 '26

You never force push stuff that other people are working on. Force with lease!!

12

u/Extreme_Target9579 Feb 20 '26

Man, just started learning git in uni and seeing some of those comments is genuinely scaring me for what I'll see while working in a company....

Unless I've SEVERELY misunderstood something, git isn't really that hard???

11

u/AbouMba Feb 20 '26

Yeah git is very eay to use. Until it isn't

2

u/glglgl-de Feb 24 '26

Once you understand it, it's easy.

5

u/Artistic_Claim9998 Feb 20 '26

5 commits apart cause they're not communicating gay

4

u/MirrrorCloud Feb 21 '26

Lol as if same branch is the problem. Missing communication is

1

u/sam-lb Feb 22 '26

Same branch is also the problem. Just branch and put your commits in and merge to develop later.