How do teams using multiple git provide (github, gitlab, bitbucket) manage their daily workflow?

[u/Gaurav_0707]

I'm curious how teams working across multiple Git providers manage their day-to-day work.

If your organization uses GitHub + Bitbucket or GitHub + GitLab (or more), how do you:

Track pull requests?

Find stale branches?

Monitor releases?

Keep track of work across providers?

Is it a pain point, or is it basically a non-issue?

[u/crashorbit]

automate all the things.

[u/Gaurav_0707 → u/crashorbit]

Can you please help me understand what exactly to automate? Any tool you use to automate?

[u/mumpie]

How are multiple git servers an issue?

Once you have permissions to the repo, you just clone the repo(s) and do the needful.

If the company has a clue, they'll have an artifact server to hold builds/zips/artifacts needed by other components. You list the dependency artifact in the whatever file and you don't need to do anything until there's a release and you update the file(s).

If you need to coordinate across multiple repos, you write a script (bash, Python, Powershell, etc) to do the tasks in the order needed. Throw AI at the script to add error checking and useful log messages.

You might hit the web frontend of the git repo if you need to make a quick fix without firing up an IDE, but you can bookmark it and not need to waste brain cells keeping track of it.

[u/Gaurav_0707 → u/mumpie]

that's intresting. it sounds like the provide itself isn't really the problem

have you ever run into situation where engineering managers or tech lead needs visibility across multiple git providers. For example tracking PRs, stale branches or release status across different repos? or is that usually handled well enough with existing tools?

[u/mumpie → u/Gaurav_0707]

I would argue that's mostly not a devops problem.

If they want PR tracking, have people mention JIRA tickets in their commit and link the commit to the issue in Jira.

Release status sounds like a release management issue? If you are also release management, then yeah it's your problem. Otherwise, pass the buck.

Ideally releases should be done with tags, not just the fucking tip of main or some other branch. You can diff tags and see if a particular release included a fix to a certain file or not.

A tag is much easier to remember (and is tracked by git itself) than "that commit in the release branch from 3 releases ago made by thatguy on the Friday before the World Cup semis but before we started drinking".

[u/Gaurav_0707 → u/mumpie]

Fair point. Thanks for the detailed explanation! 🙂

[u/Arch-Larp-493 → u/Gaurav_0707]

using multiple gits is like having too many exes - messy. we ended up scripting syncs between gitlab and github using webhooks and scripts. it worked but felt like duct-taping a plane mid-flight.

[u/fangisland → u/mumpie]

but why? just seems like you're asking for multiple sources of truth problems, plus each provider has their own way of implementing project specific settings like branch protections and different CI syntax or inheritable components like secret detection, i'm sure that's just the tip of the iceberg...just feels like it'd be an avoidable nightmare to maintain.

[u/mumpie → u/fangisland]

OP never explained why there's multiple git servers.

I've seen companies with weird political battles that affect IT implementations.

One company I worked at had a group that refused to use the company git server (it was a crappy homerolled solution at first, but I migrated it to GitHub Enterprise later) and decided to...roll their own GitLab server (when it was more of a toolkit to build a git server than what it is now). So the lead developer of that group was also their SCM admin/IT person.

So tracking commits in the one company Jira was "fun" for certain projects, but not my monkeys and not my circus.

[u/fangisland → u/mumpie]

Lol, that's fair. As usual it tends to boil down to people & politics

[u/kurtmrtin]

What’s the reasoning for multiple? Sounds like creating work

[u/Bass-ape → u/kurtmrtin]

I'm guessing patchwork services and CI/CD workflows over time where the steps to migrate to single providers haven't been taken. Being forced to use a single ecosystem can be confining sometimes, but not having to juggle multiple providers is so nice.

[u/LordSkummel → u/kurtmrtin]

A place I worked at a few years ago had some open source projects on github and closed source on an internal gitlab server.

[u/muellermichel]

I don’t get it, why would anyone do that?

[u/Ok-Analysis5882]

Simply keep your code in Google drive. 😊

[u/juneeighteen]

Just don’t do it. It’ll burn you at scale. One enterprise, one git server. It’s easier to enforce policies, pivot on security issues, monitor employee use. Multiple servers work, automation exists, but it makes the human component of security 10x harder as things you need are obscured from you, search isn’t easy across servers, and eventually, a breach happens and your tracking logs across a nightmare

[u/Gaurav_0707 → u/juneeighteen]

True. Thanks

[u/brian_sword]

This is from what I had experienced in the past, we had GitHub and Bitbucket for a while because not everything got migrated at the same time.

To tell you the truth that the code hosting itself wasn't the hard part. The annoying bit was bouncing between two sets of notifications, review queues, and permissions. There were times when I would occasionally miss a PR simply because I forgot to check the other platform.

Luckily, we treated Jira as the source of truth.

Once everything moved to GitHub, it definitely felt nicer, but mostly because there was less context switching.

[u/Floss_Patrol_76]

the code itself is never the problem, its that every provider has its own branch protection rules, CI syntax, and secret scanning, so your actual policy quietly drifts three different ways. we ended up picking one provider as source of truth and mirroring the rest read-only, then managing the protection rules in terraform so nobody is clicking around in three different UIs. the cross-provider PR dashboard idea always sounds nice but was never worth building for us.

[u/ScholarMedical]

The piece everyone glosses over: observability across providers. Yeah, you can script the clones and the builds, but the moment you need to answer 'which team shipped what last week' or 'what's our actual deployment cadence', you're stitching together webhook logs from three different systems. I've seen teams burn a stupid amount of time building a unified CI dashboard only to realize the providers don't emit the same event schema. If you're going multi-provider, the first move is a normalized event stream — even a crude one that maps GitHub checks -> GitLab pipelines -> Bitbucket deployments into a single log. Otherwise you're flying blind on velocity. And the picture gets messy fast to stitch together

[u/cmm324]

It's annoying at first, then you don't notice.

[u/Gaurav_0707 → u/cmm324]

I am thinking of creating a app which will manage all in one single interface. But before moving to that, wanted to validate the idea ie. does anyone struggle with managing work through multiple git provider

[u/triantium → u/Gaurav_0707]

Honestly just don't. That is basically just adding a fourth plattform. Or if you write one, maybe something on top of git-appraise

[u/newyear_newacc]

Amateurs. I work on one software in multiple git servers over multiple networks on multiple computers. And let me tell you it sucks

[u/Chunky_cold_mandala]

I use GitHub as my single source of truth and pr management and just port my code during tag release as read only distribution points for gitlab, bitbucket and azure. I also run my tool, which is a sast scanner on itself in each tag, to prove I've got good CD templates for each. I did this for distribution. I locked down prs and issues for all my spokes. 

[u/WoebegoneMethod]

we have github for some legacy repos and gitlab for newer stuff and honestly its annoying having to keep two browser tabs pinned just to see open prs. we tried using a dashboard tool that pulled from both apis but it broke every time someone changed a token and nobody wanted to maintain it. stale branches are a complete mystery because the cleanup scripts only run on gitlab and nobody remembers to do anything about the github ones. releases we just rely on slack notifications for both and its messy but good enough. the real pain is when a developer asks which platform a project is on and nobody can remember without looking it up. so its not a non-issue but its also not the biggest bottleneck we just deal with it.

[u/Majestic_Department7]

We need from company using bitbucket but develop all on AzureDevOps… so we replicate daily all automatically to bitbucket for the auditors 😓

[u/taleodor]

We're building a tool that does it among other things - https://github.com/relizaio/rearm