{"id":21270718,"url":"https://github.com/explodingcamera/yags","last_synced_at":"2026-01-02T15:31:56.181Z","repository":{"id":129697349,"uuid":"253472789","full_name":"explodingcamera/yags","owner":"explodingcamera","description":"The Last Git Branching Model You'll Ever Need","archived":false,"fork":false,"pushed_at":"2020-07-13T13:48:02.000Z","size":28,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-01-22T02:32:07.030Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/explodingcamera.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-04-06T11:07:33.000Z","updated_at":"2021-12-14T22:26:51.000Z","dependencies_parsed_at":null,"dependency_job_id":"ac84f65a-47fd-4d46-b425-07373c14951a","html_url":"https://github.com/explodingcamera/yags","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/explodingcamera%2Fyags","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/explodingcamera%2Fyags/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/explodingcamera%2Fyags/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/explodingcamera%2Fyags/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/explodingcamera","download_url":"https://codeload.github.com/explodingcamera/yags/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243725634,"owners_count":20337670,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-21T08:18:26.138Z","updated_at":"2026-01-02T15:31:56.154Z","avatar_url":"https://github.com/explodingcamera.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Yet Another Git Strategy\n\n\u003e The Last Git Branching Model You'll Ever Need\n\n# Key Benefits\n\n- Opinionated\n- Simplifies CI/CD\n- Supports Hotfixes\n- Good Tooling Support\n- Works with all sizes of teams\n- Improves Collaboration\n\n# Table of Contents\n\n- [Overview](#overview)\n- [How It Works](#how-it-works)\n  - [Feature Branches](#feature-branches)\n  - [Commits](#commits)\n  - [Releases](#releases)\n  - [Pre-Releases](#pre-releases)\n  - [Hotfixes](#hotfixes)\n  - [CI/CD](#ci-cd)\n- [Commit Types](#commit-types-based-of-the-angular-convention)\n- [Reccomendations](#reccomendations)\n- [Inspiration](#inspiration)\n\n# Overview\n\n![Graph](./graph.svg)\n\n# How It Works\n\nWe have one main branch in our Git-Repository called `develop`. This is our current development version, which is always deployed to our staging environment. All other branches are started off of this default branch.\nWe also have a `production` branch. This is the code that is currently running in production.\n\n## Feature Branches\n\nGenerally, new code is written in new, short-living branches, however this model does allow for small and concise changes to be pushed directly into the `develop` branch. This is only acceptable if the changes are small or cosmetic, have already been tested and don't require a code review.\n\nFor all other code, you should create a new branch off of develop. These have a naming convention:\n`\u003ctype\u003e/\u003cbranch-name\u003e` (e.g `feat/user-info-api`)\n\n```bash\n$ git checkout develop\n$ git checkout -b feat/my-new-feature\n```\n\nWhile working, track your progress in a [draft (github)](https://github.blog/2019-02-14-introducing-draft-pull-requests/) or [Work In Progress Pull-Request (gitlab)](https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html) and request a review from at least one teammate when you have finished your feature. When all checks pass (assuming you have set up [CI/CD](#ci-cd)) you [squash and merge](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits) the branch into develop (It's recommended to [require a linear history](https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history) and [disable other merge types](https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests) on your respective git host).\n\n## Commits\n\nWhen commiting your code to these branches or `develop`, you also need to follow a naming convention (based on [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)):\n\n```\n  \u003ctype\u003e[optional scope]: \u003cdescription\u003e\n\n  [optional body]\n\n  [optional footer(s)]\n```\n\n```bash\n$ git commit -m \"feat: add database user model\" \\\n  -m \"BREAKING: This changes some names in our rest-api\"\n```\n\n## Releases\n\nBefore releasing a version to production, it is recommended to sanitize-check your current staging environment — even if all tests pass. If you are confident, the next step is to (optionally) commit a version bump to `develop`:\n\n```bash\n$ git checkout develop\n$ # bump your version to v0.1.0\n$ git commit -m \"chore: bump version to v0.1.0\"\n$ git tag v0.1.0\n$ git push --tags\n```\n\nThe final step then is merging this to your `production` branch:\n\n```bash\n$ git checkout production\n$ git merge develop --ff-only\n$ git push\n```\n\n## Pre-Releases\n\nPre-Releases are just tagged development versions. To for example automate pushing your library to npm or similar, you need to add a release step to your CI/CD system that runs on every tag `*-{alpha,beta}.*`\n\n```bash\n$ git checkout develop\n$ # bump your version to v0.1.0-beta.0\n$ git commit -m \"chore: bump version to v0.1.0-beta.0\"\n$ git tag v0.1.0-beta.0\n$ git push --tags\n```\n\n## Hotfixes\n\nHotfixes should be created as pull-request from a fix-branch directly to production. These can then be reviewed and squash-merged like normal branches.\n\n```bash\n$ git checkout production\n$ git checkout -b \"hotfix/fix-password-hash\"\n```\n\nAfter a hotfix lands in production, a more elaborate fix can be created for develop or the fix can be cherry-picked:\n\n```bash\n$ git checkout develop\n$ git cherry-pick 3af9286 # the commit sha of the hotfix\n```\n\n## CI/CD\n\nContinuous Integration and Continuous Delivery are crucial parts of YAGS. Depending on your setup, this can look very different, but the general recommendation is:\n\n- `on every commit, anywhere`: Run all tests and try to build\n- `on every commit to develop`: Deploy to your staging environment\n- `on every commit to production`: Deploy to your production environment\n\n# Commit/Branch Types\n\nThese add human machine-readable meaning to your commit messages and branches (based on the [Angular Commit Convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) / [Conventional Commits](https://www.conventionalcommits.org/))\n\n- `feat` - A new feature\n- `fix` - A bug fix\n- `chore` - Changes that don't affect any code, e.g. releases\n- `build` - changes in the build system\n- `docs` - Documentation\n- `style` - Cosmetic code changes\n- `refactor` - A code change that doesn't fix/add anything new\n- `perf` - A code change that improves performance\n- `test` - Adding or correcting tests\n\n# Recommendedations\n\n## Tools\n\nWhile this git strategy will work with any combination of build/test tools, these can serve as a good starting point for new projects\n\n### NodeJS/JavaScript/Typescript\n\n- Pre-Commit Hooks with [Husky](https://www.npmjs.com/package/husky)\n  - one hook running your tests\n  - one hook running [commitlint](https://github.com/conventional-changelog/commitlint)\n- ESLint for linting TypeScript/JavaScript code (optionally with my [eslint preset](https://www.npmjs.com/package/@explodingcamera/eslint-config))\n- [release-it](https://www.npmjs.com/package/release-it) with @release-it/conventional-changelog and github releases enabled\n\n## Opensource Projetcts\n\nThese are some recommendations specifically for opensource-projects. They don't really have a lot to do with this strategy but could be helpful.\n\n- Add a [Code of Conduct](https://www.contributor-covenant.org/) to your project\n- Choose a [simple Open-Source License](https://choosealicense.com/)\n\n# Inspiration\n\nI've been heavily inspired by [Trunk Based Development](https://trunkbaseddevelopment.com/), the [GitHub Flow](https://guides.github.com/introduction/flow/) and the [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html).\nWith YAGS, I've aimed to take the best Parts of all of these and create a lightweight, opinionated and very practical alternative.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fexplodingcamera%2Fyags","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fexplodingcamera%2Fyags","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fexplodingcamera%2Fyags/lists"}