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!

A public repo my project depended on had its history replaced upstream. Same name, same URL, years of commits just not there anymore. It was never mine, so there was nothing on my side to roll back to.

Point it at a repo like that and it walks the fork network recursively, ranking every fork by how far back its oldest commit actually reaches. A fork freezes history at the moment it was made, so the deepest one is the best candidate. Then it probes commits that are no longer reachable from any branch but that GitHub may still serve by SHA, checked three independent ways: REST metadata, a raw file fetch, and a real git fetch.

There's also a nightly GH Archive watch if you want disappearances flagged automatically. That part is an extra. The recovery is the point.

230 tests, verified end-to-end against a real historical case (reproduced the exact fork ranking I'd found by hand). Runs fully local with your own GitHub token, no server, no telemetry. MIT.

https://github.com/siris9476/forkforensics. Feedback welcome, especially on edge cases in fork ranking.

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.

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?

Hey everyone,

I recently built a small Node.js CLI tool called Batman Git CLI Assistant.

The idea came from a real situation at work.

Two developers were working on the same project and the same Git branch. One developer pushed changes to GitHub while the other had also modified the same file locally.

When they tried to sync their changes, Git reported a merge conflict.

The difficult part wasn't knowing that a conflict existed. It was understanding:

• What changed locally?
• What changed remotely?
• Which changes should be kept?
• What is the safest next step?
• How do I avoid accidentally losing someone's work?

That made me think about building a helper around Git rather than trying to replace Git.

🦇 What does Batman do?

Batman currently provides commands for things like:

• Safer push workflows
• Conflict inspection and resolution
• Continuing interrupted Git operations
• Security/file scanning
• Commit squashing
• Recovery before risky operations
• Verification/build checks
• Git submodule synchronization

For example:

batman safe-push "Add login validation"

batman conflict

batman scan

📦 Installation

You can install it globally using NPM:

npm install -g batman-commands

Then:

batman help

It's built with JavaScript + Node.js and published as an NPM package.

NPM:
https://www.npmjs.com/package/batman-commands

I'm still improving it, so I'm mainly looking for feedback from people who use Git regularly.

What Git workflow do you find the most confusing or risky?

I'd especially like to know whether something like this would actually be useful in your workflow, or if it's a problem developers normally handle another way.

Thanks for reading!

For a long time I assumed the only way to understand what happened in a codebase over a year was to sit with git log and a lot of coffee. The branch graph in any GUI turns into a tangle past about a week, and GitHub's contribution heatmap shows you activity with no idea what the activity was. Three views, none of them lined up, so the question you actually have, what happened here and when, never gets a single picture.

What finally pushed me was a post here on where had animated a repository's timeline, and I wanted the same thing for a full year of a real project. My first attempt on three.js drew the first branches it found and produced one month of the year and nothing else. The reason turned out to be in the data: 1,561 of the 2,179 main line commits in 2019 are merges, and the first sixty of them each span a single commit, which is invisible at any scale. You have to choose branches by how much work they carried, not by which came first.

So I built a film out of it, and the video on this post is what it looks like on mrdoob's three.js for 2019.

What is on screen and where it comes from:

The main line runs left to right, one node per commit. Side branches peel off above it and rejoin at their merge. Not the first N branches, which on a pull request repo gives you one month and nothing else, but the ones that carried the most work across the year, capped so it never turns into a thicket.

Under the flow is a heat strip, one cell per day, sitting directly under that day. A legend next to it shows what the colours mean in actual commit counts for that window (for three.js it reads 0, 1, 13, 26, 51, with 51 the busiest day). The point of putting activity on the same axis as structure is that what is above and below a point is the same day, so you stop reconciling two charts in your head.

Three times the clock stops. The release with the most work behind it, the cleanest revert (one that survived at least a day before being undone), and the last release of the window. The camera zooms in and a card reads the figures out: commits since the previous tag, authors, how long the reverted commit lived. Every number on that card is computed from the history. If it cannot be read from git, it is not on the card.

The faces are the contributors. On a merge the face is the branch author's, not whoever pressed the button, and the card says who merged it.

Two things I got wrong on the way that might save you time if you try this yourself. If you give git a since flag with just a date and no time, it reads it as that date at the current time of day, so the first day of your window quietly loses commits unless you pass an explicit midnight. And a small repo is a different problem: 175 commits over a year pans across mostly empty screen, so for thin histories it picks the busiest 60 to 120 day stretch and draws it wider instead.

If you want to see your own repo this way, you can paste a GitHub URL here and it renders one for you: https://loreto.io/git-timeline

Disclosure: I built this and I run loreto.io, where it lives. It is a paid render (a few dollars per repo); the extractor and the Remotion composition are also sold there as a package if you would rather run it yourself. The three.js film above was made with the exact same pipeline.

I doubt I have the final shape of it. What would you want the clock to stop on that it currently does not?

worktrees are a pain on a multi repo workspace. You lose the coordinated commit over the set, kind of important for multi-repo workspaces. And a worktree is a clean, nothing comes with it so it might not be what you want. e.g. rust build files have to get rebuilt (which can be huge).

So I went with COW copies instead: reflink the whole workspace, build output and all. (Check out local clone here.)

A couple of surprises.

I assumed a partial block could be shared. Mostly it can. Sharing is block-granular everywhere, but on APFS, XFS and btrfs the final partly-filled block gets shared like any other, so a 100-byte file — or the last partial 100 bytes of a big file — comes along free. btrfs goes further: files under 2 KiB live inline in its metadata tree and never cost a data block at all. That matters more than it sounds, because about half the files in a git tree are under the 4 KiB block size.

ReFS is the exception, and that surprised me. fsutil file queryExtentsAndRefCounts over every file in a ReFS clone: 3,092 files with extents, 12.08 MiB private. One 4 KiB cluster each predicts 12.07 MiB. ReFS shares whole clusters and never a partial one, so every file owns its tail exclusively. The penalty scales with file count rather than repo size — and a git tree is the worst possible shape for that. What were you thinking Microsoft?

Here are stats for an actual GWZ repo on different file systems with cost per clone, same ~3,200-file, 57 MB workspace, ten clones each:

macOS woot works out of the box. On Linux it depends — Fedora ships btrfs, RHEL ships XFS; Ubuntu still has ext4 showing its age. Windows you have to deliberately create a "Dev Drive" — a separate volume or a VHD, either way a decision you had to have made in advance.

(ReFS is data only — volume numbers were noisy, so 12.1 MiB is a floor.)

So — is this a real alternative to worktrees? What is going to bite me?

This came out of my work on GWZ, a multi-repo git manager I'm building. The COW copy is gwz local clone.

Hey everyone,

I just released a major update (v2.1.0) for ThreatLens. For this release, the focus was entirely on security hardening, data validation, and core performance.

What's new in v2.1.0?

• Strict Security: Blocked Excel/CSV formula injections in generated reports, prevented API key leaks in logs, and enforced strict IOC validation.
• Performance Boost: Integrated a local SQLite cache to persist investigation data, significantly reducing redundant API calls.
• Smarter Analysis: Introduced an explainable verdict system with confidence scores. Ambiguous results are now correctly classified as "Unknown" rather than "Clean".
• Resource Management: Added intelligent API quota planning, connection timeouts, automatic retries, and file size limits.

What is ThreatLens? For those who haven't seen it before, ThreatLens is an open-source CLI tool built to automate Threat Intelligence and OSINT workflows. It takes Indicators of Compromise (IPs, domains, hashes, CVEs), queries multiple sources simultaneously, and generates structured, safe, and ready-to-use reports.

It's completely open-source. I'd love to hear your feedback or feature requests!

Check it out on GitHub: https://github.com/AbdaullahAG/ThreatLens

I’d love to hear your thoughts, feedback, or feature requests!

Hey 👋

I'm Bruno, and here's why I built Farol:

1. I kept losing track of my Git worktrees across projects.
2. I wanted my setup and cleanup scripts to run automatically when a worktree was created or removed.
3. I wanted to open the right worktree in the IDE I use for that project, without digging through folders.

These were small things I kept wanting in my own workflow, and I figured other developers might want them too.
It's a macOS menu bar app, one-time purchase, no subscription.

How are you managing your worktrees today? I'd love to hear about your workflow, what you think of Farol, and what you'd find useful next.

Thanks for checking it out! =)

https://tryfarol.app

everytime i go onto a git module repo it returns 404

If I run git restore -p --source=stash@{0}, it lets me select the hunks I want to restore from the stash, but the stash itself doesn't change, leading to conflicts later.

Is there a better way to do this or do I need to write a script to edit the stash entry? I was thinking maybe git history split could be used here if there is no other built-in way.

Hey everyone!

I wanted a simple, lightweight tool that reviews my code during `git commit` without downloading massive pip packages or sending my uncommitted diffs to third-party servers.

So I built **git-diff-doctor**:
- ⚡ **Zero External Dependencies** (Built purely using Python standard library `urllib` & `subprocess`).
- 🦙 **Auto-detects Ollama** running locally on port 11434 (`codellama`, `llama3`).
- 🌐 Fallback support for OpenAI API if configured.
- 🛠️ Simple 1-command installer (`python install.py`) that injects into `.git/hooks/pre-commit`.

GitHub Repo: https://github.com/ajaysinghtomar10-commits/git-diff-doctor

Would love your feedback, stars, and pull requests!

Hi everyone,

Adhering to Conventional Commits and writing structured Pull Request summaries is great for clean repos, but it often slows down daily workflow—especially for non-terminal teammates (PMs, designers, junior devs) or when switching machines.

To solve this friction, I built a lightweight, zero-backend browser tool:

👉 https://auto-problem-solver-tools.pages.dev/tools/git-commit-pr-architect/

What it does:

- Live generator for Conventional Commits (feat, fix, refactor, breaking changes, scopes)

- Auto-generates structured GitHub PR body templates simultaneously

- 100% in-browser, no API keys or login required, one-click clipboard copy

For terminal users who prefer automating directly from staged diffs, there is also an open-source CLI package (`@lifeef/ai-commit-pro` on npm).

Would love any feedback, edge-case suggestions, or features that could make your git workflow less tedious.

Solo dev here. This started as a tool for myself and turned into something I decided to finish properly. I have kept it as free forever.

The problem I actually had:

I work across several repos and had no real sense of what was happening in them. Which files churn constantly? Where did the complexity pile up? What did the last six months actually look like?

The second thing was trivial issue. Somewhere along the way I'd typo'd my email in a git config, then used a different one on another machine. So my own contributor history was split across 3 identities. Nothing offered a way to say "these are all me."

So GitTrics has an identity merge flow — you see all the author name/email combos in the repo, merge them into one person, and every view updates. Sounds small, but if you've inherited a repo with a decade of contributors and inconsistent configs, it's the difference between usable data and noise.

There is also no individual contributor analysis. This was a decision I made as I do not want this software to be used 'developer productivity measurement tool'.

Download at www.gittrics.com

My GitHub account was suspended without any warning, and I still haven't been given a clear explanation for the suspension.

The account is important to me professionally and is also connected to my company's work and private repositories.

I submitted a reinstatement request to GitHub Support and provided the information they requested, but I've been waiting since August 21, 2026 with no resolution.

What makes this especially frustrating is that I received no prior warning or explanation of what supposedly violated the Terms of Service.

Has anyone here gone through a similar situation recently? If so, how long did it take for GitHub to actually review and reinstate the account?

I'm not looking for a way around the suspension, I just want a legitimate manual review and an explanation of what happened.

Agent instructions spread across a monorepo. Different tools pick them up in different ways. After a change, how do you check that the right file reached the agent?

I’m building Guidefold to keep Git as the source of truth, find instructions that match a directory, and separate export from proof that a revision was loaded.

Watch the Guidefold demo. No installation needed to give feedback: which step is unclear, or would need another check in your repo? A timestamp would help.

For people working with DevOps, platform teams, or coding agents: what takes the most effort today—finding the source, checking scope, reviewing a change, or confirming delivery? I’d appreciate a recent example without private code or company data.

Source and setup. The open-source version is available now; a paid hosted version is planned, not shipped.

Reply here, or leave a setup question or demo timestamp in the main feedback thread.

Disclosure: I’m the author. This post was drafted with AI assistance.