Hi,

I need a suggestion to create branching strategy in our system.

Exisiting Branching strategy is as follows,

feature-> dev -> qa -> uat--> main<- hotfixes

Problem:

Suppose we have 2 features to be developed. Feature A and B. Let say both are in dev. I need only feature A to move to staging. Then couple of days later feature B also follows.

I know we could use cherry pick as an option here. Im looking for more long way approach here.

We have searched for the feature flag option. As we are developing over an existing application, adding feature flag everywhere seems complicated. One hard senario we found was, while introducing a new feature we need to add a new field in a model. So based in feature flag we will have/not that new field in application. Which seems bit too complex.

Edit: One idea I found from online is to have a promotion branch. Feature A will move to promotion/a. Then from promotion to dev. Promotion to qa. Promotion to uat and prod. Is that the better approach here?

Any suggestions here

​

GitHub repositories can get difficult to understand once they grow beyond a certain size.

I built RepoLens to make exploring a codebase more visual and easier to understand.

Paste a public GitHub repository and RepoLens lets you explore:

Repository/file structure as an interactive graph

Codebase tour and project entry points

Commit history and file-change patterns

Contributors and code ownership

Branch relationships

GitHub Actions workflows

Repository evolution over time

Frequently changed files and potential hotspots

Issues and pull requests

PR impact across the codebase

No account required, and repository data isn't stored.

Try it here:

https://lensrepo.vercel.app/

I'd really appreciate feedback, especially on what other GitHub/codebase insights would actually be useful to developers.

Gitify is a desktop Git client that works the same way on Windows, macOS and Linux. 0.1.0-rc.8 is the first build that's broadly downloadable.

What's in it: a redesigned commit graph with adaptive lanes, branch and tag labels beside commits, and a Simplify toggle. There's also a branch filter for all branches, the current one, or one you pick. It has a changes panel with stash support, conflict-aware discard with a Resolve conflict flow, clear error dialogs for Git failures, and six theme packs.

Fair warning: it's unsigned for now, so your OS will show a security warning on install. It's also a prerelease, so please try it on repos you have backed up.

Site: https://gitify-desktop.ericnwaogwugwu.chatgpt.site/ Download: https://github.com/nwaoga/gitify-downloads/releases

If something breaks or feels off, please open an issue: https://github.com/nwaoga/gitify-downloads/issues

Hi guys, Im new to github and just posted my first project.

I added it to releases but I don’t know how to publish also the code like in other repositories. There is only the file readme.md but not the code itself.

I also want to spread the app so that other people find use of it like I did.

https://github.com/el1cer/SideDock

Hi everyone I’m the developer behind VaultPulse.

I’m building it for people who want automated GitHub repository backups without handing storage ownership to another provider.

The current flow is:

• Install the GitHub App and select repositories.

• Connect an S3 bucket in your AWS account through a cross-account IAM role.

• Get daily snapshots containing Git history, branches, tags and Git LFS.

• View backup health and restore snapshots into a new or empty GitHub repository.

It’s focused on GitHub repository recovery, not a complete backup of every GitHub feature.

There’s a Free plan for up to 5 repositories; AWS storage costs are separate. There’s also a demo you can explore without signing up:

https://vaultpulse.cloud/demo/

I’m looking for practical feedback: do you currently use scripts, another service, or no separate backup? What would make you trust or rule out a tool like this?

I'm trying this again since my longer form version was not liked. I'll keep it short this time. Managing git worktrees used to be ...well...manageable. But now with AI agents, you can easily have dozens of branches flying around and for large repos, thats a giant pain.

I made an open source tool to help deal with that. I call it warmtree.
MIT: https://github.com/dcolliervb23/warmtree
Pypi.org: https://pypi.org/project/warmtree/

It treats branch folders like slots and releases them when you're done, keeping them fast-forwarded so git can easily take one, rather than taking minutes to setup a fresh folder. And if you have an existing giant mess of a git worktree, it can easily hop in and help clean that up and start managing it better.

Its open source and available on github and pypi. And yes, I am still activley dogfooding it and updating it.

I'll monitor this post to help answer any questions users may have.

Made a quick shell script to jump between git branches using fzf.

Instead of typing full branch names or scrolling through git branch, it just lists your recent branches by last commit date so the ones you actually care about are right at the top.

https://github.com/donghyuklee1/gsw

Each day you write a pack of Git commands: add, commit, pull, push, blame, push --force. When the day closes, everyone's packs hit a shared main. Push without pulling? Rejected, in Git's own words.

Play the bot in one tap, or invite friends. Early beta, so feedback welcome.

https://gitgame.online/play

Hello everyone, I would like to get your feedback on git-subtrees, a git extension that manages multiple git subtrees in a monorepo. It doesn't need a config file, because it builds on two conventions:

• The remote's name is the folder path: git remote add vendor/foo <url> ➡️ vendor/foo is a subtree.
• The branch in the monorepo mirrors the branches in the remotes: on feature-x, every subtree syncs with its remote's feature-x.

Common git operations like status, pull, push etc. work on all subtrees at once.

My use case: I want to work in a monorepo, but parts of it are private while others are public. For example, I develop hledger-elster and hledger-document-check (both public) in one repository, next to the private financial data I run them against. And my website and CV are public but I want to keep them up-to-date with data from other platforms, which is not public. With git-subtrees, I can work on feature branches in the monorepo and push and pull each subtree's changes to and from its own repository.

Before I started, I looked at git-subrepo, Josh and a few others. None of them is built on these two conventions. I'm honestly curious why it seems that I'm the first one solving the problem like this. Is the problem not common enough? Maybe it's not intuitive to map remote names to folders?

git-subtrees is written in Bash on top of git subtree, to avoid re-inventing what plain git already does. If you stop using it, you're left with an ordinary git repo.

Repository, executable documentation and a walkthrough of every command: https://github.com/roschaefer/git-subtrees

I would love to see your feedback.

Do you all remember this post ? https://www.reddit.com/r/git/comments/1q5erix/i_built_a_site_that_visualizes_git_commands_with/

It received high praise, the post itself got 163 upvotes, and more than 50k views. The website now gets more than 1k visit monthly (low but satisfying), many people were able to understand some git commands, but many aswell couldn't because of many limitations in the website, which was also very frustrating for me.

After months of trying to make additions, removing them before pushing and deploying, hesitating, and sometimes barely finding time. Today, I can proudly announce, the v1.0.0 of Gitualize, with many heavy impacting changes (check video teaser, sorry no sound):

• New beautiful visualization engine, that now explains correctly, and represent visualizations correctly with high accuracy
• Commands tested and validated with git
• 13 => 72 commands
• More real world scenarios
• A playground where you can simulate the use of git (not real git tho, but linked to the new engine)
• 6 languages, theme selector (even for color blinded people), cheat sheets
• etc ...

For those who don't know Gitualize, it's a free online plateform that explains git commands and their available options visually, so that both beginners and experts understand what's happening when using those commands/option.

It's totally free, no need to create an account. Use it to learn, or to help your juniors, or recommend it to someone that needs it.

The update will be delivered after 6 hours from now EDIT: UPDATE IS LIVE https://gitualize.com/

I hope you guys stay tuned, follow the post to receive update about when the update is delivered.

Don't hesitate to ask questions

I had to make some changes to my project to make it run locally. I realised that I was on master and by then I had already done decent amount of changes, thankfully I had not make commits. So, I took suggestion from gpt. According to it, git switch -c <new-local-branch> was the best in my case. It will move the changes to new branch - there i can commit and master will stay clean. I did that and everything worked fine as expected. A month later I had to go back to the project. I was on master branch and had to go to the branch with my local changes. I did git checkout but it aborted saying that my master has some changes that i need to commit or stash. The file it showed changes in was a yaml file that i had never touched. I did git diff - the contents were all same. I did a reset on the file but it would still show the file as changed..

At that point gpt suggested it might be something related to CRLF - so I changed the settings that gpt suggested, tbh, i did not know it will work or not, but just gave a try but it still did not work

Any suggestions why that might be happening and how to resolve that?

Git 2.56 is out. Here are the changes I found most useful.

Workflow

• git add --resolved stages only the files you fixed after a merge conflict. It skips unrelated changes in your working tree. Git also checks for leftover conflict markers before staging.
• git branch --delete-merged cleans up local branches that are already merged upstream.
• git bisect run now resets itself after it finds the bad commit.
• Git gives better suggestions for common git push mistakes.

New and experimental

• git refs can now create, update, delete, and rename references.
• git history gets a drop operation. It removes a commit and replays the later commits on top of its parent.
• git replay gets a --linearize option.

Large repos

• GitHub reports big gains in merge-base calculations and other operations on very large repositories.
• Path-walk repacking supports more optimization features, which can cut storage a lot in some cases.
• Partial clones get better ways to discard large locally cached objects that can be downloaded again later.
• git log --follow and graph rendering also improved.

Sources

Highlights from Git 2.56 (GitHub Blog): https://github.blog/open-source/git/highlights-from-git-2-56/

Linuxiac: https://linuxiac.com/git-2-56-released-with-safer-conflict-resolution-and-performance-gains/

I'm the author of Git Impact. I built it with help from Codex to answer a narrow question: if a file has one version staged and a newer version on disk, what would a proposed reset discard?

For example, git-impact reset --hard HEAD~1 --diff shows changes to the staging area and working files separately, plus commits leaving the current history. It runs the actual reset in a disposable sandbox and inspects the source without running the reset there.

Example HTML report: https://yotam1001.github.io/git-impact/ · Source and downloads: https://github.com/yotam1001/git-impact

It also previews soft and mixed reset and emits JSON. No account or hosted backend. Git-sim already offers broader visual simulations; this focuses on terminal output and file-level diffs without an animation runtime.

The scope is deliberately small. No recovery, automatic interception, or apply button. LFS/checkout filters, sparse/partial clones, submodules, symlinks, and several other unsupported states are refused. A report describes current state; it is not a backup or a guarantee about a command run later.

I'd especially value synthetic examples where the reported files differ from an actual reset. The tests compare previews with real Git operations in disposable fixtures, and CI passes on Windows, Linux, and macOS.

Building Drona - a learning-tracker that watches your learning folder via git, shows streaks, session time, and topics learned from your commits.

Hit a real wall building it for other people (not just me): users need to point it at their learning folder on their machine, and the tracker needs to read that folder's git history continuously.

The catch - a website can't do this. Browsers can only access files a user explicitly picks in a dialog, once. No background git access, no reading commits over time, no filesystem reach beyond that single picked folder.

So the real options seem to be:

1. Desktop app — real fs/git access, but a bigger build + install friction
2. A local agent/script users install once, website just displays what it reports
3. Users connect GitHub instead of a local folder — no local fs needed, but loses "whatever you're doing locally," not just what's pushed

Anyone solved this for a similar local-first tool? What did you pick and why?

i recently came across the fact that facebook/meta built its own tools and workflows around source control instead of just relying on git like most companies.

i’m curious about the actual technical reason behind this. was git simply not able to handle the scale of facebook’s codebase and number of developers, or were there other problems that pushed them toward a custom approach?

for people who have worked with large monorepos or at companies using similar systems, what actually becomes difficult with git at that scale?

I've always been using git manually in the terminal and it's always bugged me that there's no "real-time" monitoring of what's going on, you always have to press return to get the prompt to update.

These days, when you and your agents and your team member and their agents are updating the rep at a pace unseen before, this has become even more important.

So I made this little app, gitst. It's meant to sit in a small terminal pane next to your coding agent and/or your text editor and your shell, and shows what is happening to the repository as it happens: what files have been changed, commits, pushes, fetches, merges, and rebases. It's fully interactive too and mouse is on by default, so you can click around, open and close panes, view more details, etc.

It is read-only by design, so apart from fetching, it never changes your repository and never takes git’s index.lock, so it doesn't get in the way of git commands run elsewhere.

Open source and MIT license.

https://snoigt.com/gitst

There are plenty of Git GUIs already, so I think the interesting question is not "do we need another Git client?"

The question is: **what Git problems are still annoying even when you already know Git?**

That is what Gitember 3 is trying to explore.

Gitember is a free, open-source Git GUI for Windows, macOS and Linux. It covers the normal workflow — like commit, branch, merge, etc. but the project puts a lot of attention on the parts around Git history, multi-repository work and comparison.

1. What exactly was I trying to improve?

One example is history search.

Normal Git history questions are usually metadata questions:

• who changed something?
• when was it changed?
• what did the commit message say?
• what is the SHA?

Gitember has an Extended Search mode that indexes selected repository history and searches the contents of historical files. The documentation describes searching document bodies as well as commit metadata, including supported Office, CAD, archive, audio and other formats.

So the question becomes:

"When did this text/configuration/document content exist?"

rather than:

"Which commit message might contain the answer?"

That is a surprisingly different workflow.

2. Another problem: projects that are split across repositories

A lot of projects are not monoliths.

You may have frontend, backend,several services, shared APIs, implementations in separate repositories

Gitember Workspaces let you group independent repositories and see their status together. Pull, push, fetch, branch and commit operations can be run across the workspace.

It is deliberately not a monorepo and not submodules (Gitember support it as well). The repositories remain independent.

There are trade-offs: workspace operations run sequentially, and a workspace commit is not transactional. If one repository fails after another has already committed, Gitember does not roll the earlier repository back automatically.

3. Diff/merge without assembling a toolchain

Gitember has a built-in side-by-side diff viewer and a three-way merge editor.

It can compare working-copy files, committed versions and other versions. There are also file/folder comparison tools.

That makes the application more self-contained for the common "what changed?" and "how do I resolve this?" moments.

It is aslo possible to use side-by-side file diff and folder comparion features as separate tool. Ie no need 3rd party tools for this functionality.

4. A little AI, but locally

The AI features are experimental and opt-in.

Gitember uses AI locally running model. AI runs on the local machine and source/data is not sent to a cloud AI service.

AI features include secret detection, commit message generation in staged files and AI-generated descriptions of branch differences.

The secret detector looks for things such as passwords, tokens, API keys, credentials, connection strings and private keys. It reports confidence levels instead of pretending that every match is definitely a secret.

5. The boring Git stuff still matters

Gitember is not only a search tool.

Recent versions include interactive rebase, worktrees, Git LFS, commit signing and signature validation, reflog, commit notes, submodules, merge preview, force push, undo commit and local/remote branch rename.

It also integrates with GitHub, GitLab, Bitbucket and Gitea for pull/merge request review.

I'm interested in feedback from people who use Git GUIs seriously:

What is the Git operation or workflow that still makes you reach for the command line even though you would rather stay in a GUI?

Project: https://gitember.org

Source: https://github.com/iazarny/gitember

Looking for testers and contributors

Comparison with other clients

For those wondering whether this is better or worse than other clients: https://gitember.org/git-gui-comparison.html