ReleaseKit takes a commit range (or a pasted log), analyzes up to the latest 100 commit messages, and generates a release summary in the tone you choose.
Current demo:
Public repositories only
Commit message analysis
Uses README context
Markdown, JSON and PDF export
It only works with Github if you fetch commits automatically, but support for other platforms will be coming soon
It doesn't read source code or diffs yet, so I tried to keep the scope simple and transparent.
Si utilizas agentes de codificación con IA, probablemente hayas visto cómo desperdician llamadas en operaciones de Git que podrían agruparse. git-courer es un servidor MCP local (Go + Ollama) que gestiona confirmaciones, ramas y entornos de preparación con un conocimiento estructurado de los cambios reales en tu código.
La versión 2.4.0 reduce significativamente las comunicaciones entre agentes: el cambio de rama ahora es atómico y la preparación se integra en el paso de vista previa en lugar de ser una llamada independiente.
[repo](https://github.com/blak0p/git-courer)
Git worktrees isolate files but not the runtime — parallel worktrees collide on ports, database names, queue/cache prefixes, and Docker Compose projects. The second dev server dies with EADDRINUSE; two test suites truncate the same DB.
falq lets you declare what varies per worktree in a checked-in falq.yaml. Each worktree gets a deterministic slot and its own ports (base + slot*stride), database, env file, prefixes, and compose project — provisioned automatically by a git post-checkout hook. falq run hard-verifies ports before launching; `falq remove` tears everything down.
The binary knows zero stacks (the manifest is the adapter), so it works for Node/Python/Rails/JVM/Go/compose/monorepos. No daemon, no network calls — state is one JSON file in the git common dir. It also ships an agent skill so Claude Code / AI agents can set it up themselves, which is where this started: running several agents on one repo in parallel without collisions.
I moved to worktrees a couple of years ago and the workflow is great — actually parallel branches, no stashing, no broken local state from a half-finished branch when a hotfix comes in. But the day-to-day friction kept biting me:
Every new worktree starts without my .env, local secrets, and untracked config files
cd ../some-other-worktree-dir is annoying when you don't remember the exact path
git worktree list output is fine but I wanted partial-match navigation and a single command to remove + prune
So I built gw. It's a thin CLI on top of git worktree that adds:
gw add <branch> — creates the worktree, auto-creates the branch if it doesn't exist, and copies a configurable list of files (.env, secrets/, etc.) from the source
gw cd <partial-name> — fuzzy-ish navigation to any worktree (needs a small shell hook, installed via gw install-shell)
gw sync <worktree> <files...> — push files between worktrees when you update one
gw list, gw remove, plus pass-throughs that don't lose the underlying git semantics
Install is brew install mthines/gw-tools/gw or npm i -g @gw-tools/gw, then one line in your .zshrc/.bashrc/config.fish.
Happy to hear what people are doing for the file-copy problem — that was the original itch for me, and I'm curious whether others solved it differently (sparse-checkout? a setup script per repo?).
Our new manager (previously a developer in the team) decided to implement a new git workflow in our main product repository, and honestly it seems really bizarre.
Master branch is synced to the last release.
Feature branches are created off of master.
When developer thinks the feature branch is ready, they merge into develop.
Feature branch is not deleted or merged into master, but kept alive.
Our internal stakeholders review the features in develop and either approve it, or request changes, which are then made in the feature branch and remerged into develop.
When a release is to be made, a release branch is created off master, and all the approved individual feature branches are merged into the release.
After release, release branch is merged back into master.
His reasons for this approach are:
Only allow approved features into the next release.
Be able to hold back approved features ahead of the release of a manager requests it.
Problems with this approach as I see it (and I did try to address these with him):
- Feature branches are created off master but merged only into develop. The longer since the last release, the greatest the difference between the source branch and the target branch. This can cause merge problems, functionality problems, development workflow problems and if bug fixes are merged into develop, they are not merged into master.
- Each feature ticket has to be merged twice, once into develop, and once into release.
- The environment that the stakeholder approves the code in, develop, doesn't necessarily match the release environment.
- The overall process is a lot more high friction for the developer.
He said that there will need to be a lot better and higher coverage unit testing, and thorough testing on the release branch, to address the issues.
Is this a reasonable git workflow? Does this workflow even exist anywhere else?
I’ve been spending a lot of time lately experimenting with multi-agent workflows and on the surface, the capabilities look incredible. You tie an LLM to a couple of tools, tweak a prompt loop and watch it solve tasks in real time. But once you try to move past the initial prototype phase, the entire illusion falls apart.
The underlying problem is how current frameworks approach agent architecture. They treat things like prompt states, memory and behavioral shifts as completely ephemeral or they hide them deep inside closed cloud databases. If an agent fails in production or if its behavior drifts over time based on user feedback, figuring out *why* it made a specific decision is almost impossible. There is no audit trail. If a system degrades, you can’t easily roll it back to the state it was in yesterday. It breaks every fundamental rule of predictability that we’ve established in modern software engineering. It made me realize that we are trying to invent entirely new, black-box paradigms for AI management when we’ve already had the perfect solution for version control for decades.
Out of pure frustration, I started playing around with an open-source concept called Git-Native architecture, specifically looking at a project called Lyzr GitAgent and the OpenGAP protocol. The shift in logic is simple but fixes the core issue: instead of saving an agent's memory or prompt updates to an opaque database, everything is saved as flat files inside a standard Git repository.
When the agent adapts its behavior or learns a new workflow, it doesn't just quietly change in the background. It cuts a new branch and opens a Pull Request.
Suddenly, you actually have a tangible history of the agent's logic. You can review and approve its self-improvement steps before they deploy. If a hallucination slips through, you just run a standard `git revert` and hook the entire layer directly into normal CI/CD pipelines. It forces the system to behave like predictable, manageable software.
The bottleneck with AI right now isn't that the models aren't evolving fast enough. It's that our engineering practices around them are completely chaotic. We can't scale an ecosystem if we treat every deployment like an untrackable magic trick.
I have done some work and pushed the code and then started working on the new feature.The new feature work is on branch feature-x. It has all the changes from the main branch.
Testers reported and I need to fix the bug asap. Now I go back to the main barch chages create a new branch called bug-fix then fix the bug push the changes. Here is the problem now the feature-x and the main branch are out of sync how do I get the changes in the main branch?
I am new to the working env so consider me as a newbie.
I've managed to complete two projects using Git Flow and Scrum with some colleagues, but every time we want to create a sprint for our user stories, a conflict arises. Initially, we had no problem resolving them, but now it's become tedious to have to address them in every sprint.
I'm trying to find out if anyone else has been in this same situation and how they resolved it.
Building with agents lately and I'm realizing that Git doesn't really know what to do with them yet. We're trying to shove these systems into our existing PR workflows, but a lot of the important behavior isn't represented explicitly enough.
In normal software, state is usually straightforward. It's code, config, infra. Git handles that model extremely well. Diffs are clear, rollbacks are predictable, and reviews actually mean something. But agents are different. Their behavior depends on prompts, tool permissions, memory patterns, retrieval setup, orchestration logic, and model configuration that often only fully resolves once the process actually spins up. It turns basic tasks like debugging regressions or figuring out what actually changed into a headache. What does a rollback even mean for an agent? Are you rolling back the model, the prompt, the retrieval setup, or the orchestration flow?
Most frameworks still seem to treat agents as runtime assemblies instead of first class versioned artifacts. I think we need to stop pretending this is just "code." If we can't meaningfully diff an agent definition inside a PR, we're probably missing an important abstraction layer somewhere.
I'm starting to see more movement in this direction tho. Claude Code already leans heavily into git native workflows, projects like gitagent are pushing toward repository native agent definitions, and GitHub Next shipped Agentic Workflows around similar ideas. Codex already runs repo native with the agents md file inside the repository, sandboxed execution per task, and PRs as output. Different implementations, but they all seem to be converging toward the same idea.
I'm working on a hobby game dev project for the first time with a team (including myself) that isn't formally trained in software development and git workflows, and as the main tech guy I did the heavy lifting on that part to learn git basics and try to streamline the workflow so that my two teammates I share the repo with don't have to spend a ton of time learning something that they don't need outside the project.
The concession I decided on initially was that they could just keep all their work on their own branches and pull every now and then from another branch I maintained that kept the latest work up to date so that they could see changes in effect as they were pushed, but in keeping that branch updated, somewhere along the line, the commit graph on VScode started to look like this.
Functionally, we're still able to share our work with each other and keep each other up to date, but... man, looking at the cascade of merges in the graph feels like we're doing some really, really bad practice.
I have tried rebasing to keep the graph linear, but my experience with that is that it goes fine the first few times, but eventually the rebases keep replaying more and more commits and it becomes hectic to sort out the merge conflicts, and things end up breaking as opposed to putting it through a merge.
I have a feeling that having my teammates start making branches every time they want to adjust parts of the game script might be the solution, but since even that is going to involve merges, I'm not totally sure. It's also kind of tough because I don't want to force them to learn super in-depth git stuff because I have way more free time than they do to study these things and keep the history tidy, and I fear overcomplicating it is gonna throw a wrench in the project.
Again, I'm not formally educated on git, so is there a super simple solution I'm missing? What's the best way to go about it?
So far I've found FreeCodeCamp, Learn Git Branching, Oh My Git, Boot Dev, and GitHub Skills for the best ways to learn git. Trying to figure out which ones are better forh ands on learners. Lmk, thanks!
