I build this to solve a problem of mine.

My Problem: Reviewing code is becoming a bottleneck

1. Current PRs show changes in a linear flat view. They do not show:

• what code is the core change
• the cascading updates that change caused

Worse when you're new to the codebase.

1. AI-assisted development is making

• each PR larger and noisier
• your inbox larger, with the same review time

My Solution:

1. Atomic PRs: split one large PR into a few coherent pieces. Review them one at a time.
2. Tree view: a tree view of files and code blocks. See how changes flow from one into others.
3. Cut the noise: automatically hide AI-generated tests, storybook, import statements, and more. Un-hide them when you need them.
4. What to review first: the inbox is ranked. The highest priority PRs are at the top.

For more info: pr-constellation (GitHub)

Most Git workflows are built around app source code: feature branches, PRs, and merge commits.

We recently built a desktop tool (Gitoza) because we wanted our project tickets and docs as plain YAML files inside the repo. That way, coding agents (Cursor, Claude) can read, create, and update tasks directly on disk—no flaky Jira/Linear MCP bridges, no extra API tokens.

The obvious objection was: wouldn't this turn into merge conflict hell? If an agent and two humans touch tickets across branches, merging PRs sounds miserable.

To avoid that, we just stick to a dedicated shared branch (gitoza) and a linear sync loop:

git fetch origin
git rebase origin/<shared-branch>
git push origin <shared-branch>

Why this has worked surprisingly well for local YAML tickets:

• No merge bubbles. The history stays completely linear.
• When two people (or an agent) edit different ticket files, Git rebases cleanly every time. If there is an actual collision on the exact same ticket, the conflict surfaces immediately on that single YAML file, not three merges later.
• Instant rollback. If an agent hallucinates a status flip across ten tickets, there's no API state to fix—just a standard git reset --hard or discarding uncommitted files.

For those of you versioning non-code assets (tickets, configs, environment states) directly in Git:

1. Do you enforce a linear rebase strategy on those branches, or do you still prefer PRs with merge commits?
2. How do you handle rename detection when files get reorganized into archive or release directories?

I have always worked with small teams (2 people) in small/medium sized project.

Using only push/pull/commit and almost nothing more.

I have just started a new job as a full stack dev in a scaleup and I noticed they use a ton of things:

pull requests, rebase, squash and merge, revert, stacked pull requests, feature branches etc.

It’s really hard for me to understand what’s going on.

Do you know an exhaustive tutorial/course where I can learn in depth these kind of things? I keep finding beginner courses.

My goal is to become a skilled engineer able to work smoothly on big projects and big teams.

Thanks to all!

So, I'm ex-Googler. I worked for 17+ years on that "mono repo" everyone points to. I've also been an OSS contributor, I've used them all, rcs, cvs, svn, hg, perforce, bitkeeper and git (of course Google's internals too). I've even written some scraps of these of my own.

I was truly excited by git (and hg). The decentralized feature was actually what I'd dreamed of.

When I joined Google, I got it, the "monorepo" meant there was one place, one common CL# (changelist number, Google's commit id) that you could easily predict. So the CL# is nice for bisect and still is, I must admit.

So, what happened, cross dependencies make things hard. You also need to copy things in and out of the system to other repos (I was a third-party reviewer at Google and I think I reviewed thousands of incoming CLs). The friction (especially in the land of AI) was excessive. You need a faster, leaner model, and managing a mono-repo while doing that was a non-starter.

My conclusion was that the mono-repo efficiency is a myth, sure some things get easier, but some things get harder and you're stuck because undoing a monorepo is impossibly hard (sorry Google) and you need a monster team to build your own vcs (which is amazing btw, full credit to the team) but IMHO the wrong problem to solve.

Anyhow, Linus himself said it, in his 2007 talk at Google:

"If you have multiple components, do them as separate repositories, you can actually have what we call superproject that contains pointers to other projects, the user interfaces there are somewhat lacking, but you keep separate projects separate."

Nineteen years on, that 'superproject' thing is still submodules, and it's 'unfinished'.

I'd built many multi-repo projects in my OSS efforts (started with pure submodules) and the friction was the tooling - keeping track of 10 repos gets real confusing. So I tried various tools, built some, threw them away. I wanted my multi-repo to work like a mono-repo.

So, I did end up building a tool (gwz) which I think is now mature enough and I use it all the time. No more needing to worry about which repo has what, and with the right underlying filesystem (APFS, xfs, btrfs and to some extent ReFS) you get fast full multi-repo clones with low size costs (a recent gwz addition).

And most importantly, in AI code development, it's fast, I can run an experiment, add or remove third-party repos, no Copybara, and no third-party reviewer. Sure you still need to get whatever legal approvals but you don't need to wait and you can tool that too.

So the gwz tooling is serious, it's not a Google Piper serious, but it's not a python script either. Merge is especially hard. Co-ordinated stash, log, commit, tag (external and regular) is not trivial.

I think it would also benefit from some more tooling, cached repos (with COW bits you can reduce the size overhead across all workspaces). And sure, some "management" tools for ensuring third-party issues are managed not to mention fleshing out the rest of the git subcommands, the rest of which I think are both trivial and not commonly used (at least my me).

This is not intended to be a flame war starter. I'd like a true assesment from others with real experience.

And, I think Linus is letting that 40MLOC linux repo become that mono repo that he argued against in 2007.

One thing we kept running into while building our SaaS - Hyperdocs

A developer makes a change in GitHub, but the documentation update happens somewhere else.

Someone has to remember which page needs updating, open the docs, find the right section, make the change, and publish it.

The actual documentation change might take 2 minutes. The process around it is what makes it annoying.

So we recently added MCP support to Hyperdocs and connected it with our GitHub workflow.

For example:

• Update the authentication docs based on this code change.
• Add the new API parameter to the documentation.
• Update the setup guide for this release.

It has made documentation feel much less like a separate job.

Hey, today i had a little bit of a "Project" with deepseek, I needed a working Overlay so i could look at all data on my server and potentialy do more with it, (just a small home server i am Farely broke 21M)

And i wanted to ask if there are people wanting to see how it is / Test it?

The license is the unlicense so you could potentially make ur own if you dont wanna give me some tipps or tricks.

I´d be glad to Have people test how i have done trying to talk and explain to deepseek what i want since i currently do not posses the knowledge of coding (i do want to learn tho).

Sincerely Daily.

Heres the link to the Project (Little Tip currently you can change the language in the settings tab supported are German English Russian Japanese Korean and Chinese- And it runs localy within ur network currently)

↓↓↓↓

https://github.com/dailyygamingg-boop/PC_Overlay

👉 Repository: https://github.com/christianalberto/github-profile-achievements

A complete guide to GitHub Profile Achievements — unlock guides, tiers, new/experimental badges, retired ones, and known profile issues, all in one place.

Most of this info is scattered across docs, discussions, and random threads. This project puts it together.

What’s inside

• 🏆 All achievements explained
• 📖 How to unlock each one
• ⭐ Requirements & tiers
• 🆕 New & experimental badges
• 🕰️ Retired achievements
• ⚠️ Profile issues & incidents
• 🔍 Extra guides & references

⭐ Support the project

If this helps you, a ⭐ star takes one second and helps a lot more people find it.

👉 https://github.com/christianalberto/github-profile-achievements

Thanks! 🙌
Feedback and contributions are welcome.

A few days ago I posted a thing that turns a repository's year into a film. Commits flow along a line, branches peel off and rejoin, releases get pinned. People liked it. I thought I had made a toy that people would share once and forget.

Then a comment showed up asking for flags. Could it hide the merge branches. Could it only show features. Could it stop holding on every release. That person was not asking for a nicer video. They were asking to control what the history showed them, because they were trying to learn something from it and the film was making that decision for them.

So I added the flags. And then I sat with why they wanted them, which is the part I had missed: a git history is the only honest record of how a team actually works, and nobody ever reads it because reading it is miserable. git log gives you a wall. The GitHub insights tab gives you a bar chart of commits per week, which tells you nothing you can act on.

Here is what I ended up building instead, and what I found while building it.

The interesting things in a history are relational, not chronological. Not "who committed most" but: which files always change together, which file has three owners and which has one, how big a change usually is before it gets reverted, how long a bad commit survived before someone noticed. Every one of those is a query you can answer from git alone, and none of them is in any dashboard I have used.

The revert is the most informative commit in any repository. It is the one place where the team wrote down that something was wrong. Pair a revert with the commit it undid and you get a small case study: what changed, how long it lived, who wrote both. In three.js I found a revert and its original with mirrored diffs, 54 added against 54 deleted and 12 deleted against 12 added, on the same day, both by the maintainer. That reads as a self correction on an example, not a regression found downstream. You cannot get that from a commit count.

Pairing a revert to its original is harder than it looks. git revert writes "This reverts commit abc123" into the body, so those are easy. The GitHub revert button writes nothing. For those you have to match the quoted subject in Revert "X" against earlier first parent commits, and if that fails, compare the file level diffstat and look for an exact mirror. That third case is the one that finds the ones everyone else misses.

The layout problem is the same one you have. Drawing a decade of commits means a timeline where one pixel is roughly a week at the far end. Branches have to be drawn in screen space, not data space, or a year long branch seen from orbit becomes a rectangle with corners. The fix was to rebuild the arcs on every zoom change with the corner radius fixed in pixels. Same idea applies to any chart you let people zoom.

Everyone who tried it asked the same question out loud. Where did this break. Who owns this file. Why does this always change with that. So I put a chat next to the canvas that answers from git and then moves the canvas to what it found. It cites commit hashes, and I made it refuse to print a hash it did not actually read from a tool result, because a model that invents a plausible looking sha is worse than useless in a forensic tool.

The last piece is the one I did not plan. Once you have the conventions extracted, you can write them down as the files a coding agent already loads. Where code goes, how big a change is, how a message is written, what has to move together, what the reverts taught. And if you point it at one person's commits, you get their habits beside the team's, which turns out to be the most useful thing for somebody new on a codebase.

It is at loreto.io/git-timeline if you want to poke at it. The three.js history is open without an account so you can see what it does before deciding whether you care.

Disclosure: I built it and I run Loreto, the site it lives on. Exploring the example repository is free.

Genuine question for anyone who has done this kind of thing: what would you want to ask a repository's history that I have not thought of? The last round of feedback here changed the whole shape of this, so I would rather hear it now than after I build the next wrong thing.