{"id":15494009,"url":"https://github.com/sarscode/git-style-guide","last_synced_at":"2025-03-28T17:13:24.179Z","repository":{"id":122786629,"uuid":"368546665","full_name":"sarscode/git-style-guide","owner":"sarscode","description":"An opinionated style guide for git","archived":false,"fork":false,"pushed_at":"2021-06-24T02:27:51.000Z","size":18,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-10-19T11:30:40.339Z","etag":null,"topics":["git","git-style-guide","git-styleguide","styleguide"],"latest_commit_sha":null,"homepage":"https://sarscode.github.io/git-style-guide/","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc0-1.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sarscode.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","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":"2021-05-18T13:47:22.000Z","updated_at":"2021-06-24T09:26:40.000Z","dependencies_parsed_at":null,"dependency_job_id":"d7346153-2516-4413-9196-523f98f4c753","html_url":"https://github.com/sarscode/git-style-guide","commit_stats":{"total_commits":8,"total_committers":1,"mean_commits":8.0,"dds":0.0,"last_synced_commit":"c82f6ca0de560b6fa406fb9a6f2301eec53dcfa3"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sarscode%2Fgit-style-guide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sarscode%2Fgit-style-guide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sarscode%2Fgit-style-guide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sarscode%2Fgit-style-guide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sarscode","download_url":"https://codeload.github.com/sarscode/git-style-guide/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246068302,"owners_count":20718503,"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":["git","git-style-guide","git-styleguide","styleguide"],"created_at":"2024-10-02T08:10:28.448Z","updated_at":"2025-03-28T17:13:24.146Z","avatar_url":"https://github.com/sarscode.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# git-style-guide \n![LICENSE](https://img.shields.io/github/license/sarscode/git-style-guide)\n![GitHub Stars](https://img.shields.io/github/stars/sarscode/git-style-guide?style=social)\n\nA sane, opinionated style guide for git.\n\n## Repositories\n\n\u003e Great repository names are *short, descriptive* and *memorable*.\n\n- Use **lowercase** for naming repositories.\n- Use **kebab-case** (hyphen separated words) for multi-word names.\n\n```\n# good\nprettier\nparcel-transformer-ejs \n\n# bad\nParcel_Transformer_EJS\nparcel_transformer_ejs\n\n# ugly\nParcel Transformer EJS\nParcelTransformerEJS\n```\n## Branches\n\nThe primary branches could be any one or more of these:\n\n- **main or master:** Production code. This branch contains code that is considered stable, possibly only code that has been or will be released. Code on this branch is deployable. Don't push directly to this branch. Merge only production ready code to this branch. This branch serves as an integration branch for production ready changes.\n- **development or develop:** This is a optional branch. Development code. It could be the most active branch. This branch serves as an integration branch for features and fixes. When a feature is complete, it gets merged back into this branch.\n- **staging:** This is an optional branch. It typical mirrors the master branch but usually for deploying to test servers. Code in this branch is usually ready and tested to be merged to the **main or master** branch.\n\nOther branches are usually short-lived.\n\n\u003e Branch names should be *short* and *descriptive*.\n\n- Use **kebab-case** when naming branches.\n- Branch names should follow this format:\n\n```\n\u003cstory-type\u003e-\u003cdescription\u003e-[ticket-id]\n```\n\n`story-type` can be one of these types:\n\n- **ft:** A new feature\n- **fix:** A bug fix\n- **docs:** Changes to documentation\n- **ref:** Refactoring production code\n- **test:** Adding tests, refactoring test; no production code change\n- **ch:** Updating build tasks, package manager configs, etc; no production code change\n\n`description` is a summary of what the branch does. It should not be more than 50 characters. \n\n`ticket-id` is optional. However, if the branch is an implementation of a ticket in an agile project or a GitHub issue, the ticket id or issue tracking id should be referenced.\n\n```\n# good\nft-user-auth-12345\nfix-scrollspy\n\n# bad\nfix\n\n# ugly\nlogin\n```\n\n\u003e Branch names could also be version names or release tag names.\n\n```\n# good\nv2.0.0\nrelease-v2.1\nversion-10.0-oreo\nv1.0.1-alpha\n\n# bad\nalpha\noreo\n\n# ugly\nnext\n```\n\n## Commit Messages\n\nCommit messages should consist of three distinct parts separated by a blank line. A title and an optional body and an optional footer.\n\n```bash\n\u003ctype\u003e(scope): \u003csubject\u003e\n\n\u003cbody\u003e\n\n\u003cfooter\u003e\n```\n\n**Title:** The is a required and should follow the format `\u003ctype\u003e(scope): \u003csubject\u003e` . When body and  footer are absent the title should contain a summary of the change in this format `\u003ctype\u003e(scope): \u003csummary\u003e`.\n\n`type` can be one of these types:\n\n- **feat:** A new feature\n- **fix:** A bug fix\n- **docs:** Changes to documentation\n- **refactor:** Refactoring production code\n- **test:** Adding tests, refactoring test; no production code change\n- **chore:** Updating build tasks, package manager configs, etc; no production code change\n\n`scope` is optional. However, if present, it should be something specific to the commit change. For example: **auth**.\n\n`subject`  should be at most 50 characters, should begin with a capital letter and should not end with a period. Use present tense to describe what a commit does, rather than what it did. For example, use **Add**, instead of **Added** or **Adding**. \n\n```\n# good\nfeat(accounts): Add user signup validations\nchore(deps): Upgrade to parcel v2.0.1\n\n# bad\nfix\n\n# ugly\nlogin\n```\n\n**Body:** is optional and only used when a commit requires a bit of explanation and context. It should be written in present tense.\n\n**Footer:** is optional and is used to reference issue tracking IDs.\n\n*Below is template guide for a commit message with title, body and footer.*\n\n```\nfeat: Summarize changes in around 50 characters or less\n\nMore detailed explanatory text, if necessary. Wrap it to about 72\ncharacters or so. In some contexts, the first line is treated as the\nsubject of the commit and the rest of the text as the body. The\nblank line separating the summary from the body is critical (unless\nyou omit the body entirely); various tools like `log`, `shortlog`\nand `rebase` can get confused if you run the two together.\n\nExplain the problem that this commit is solving. Focus on why you\nare making this change as opposed to how (the code explains that).\nAre there side effects or other unintuitive consequences of this\nchange? Here's the place to explain them.\n\nFurther paragraphs come after blank lines.\n\n - Bullet points are okay, too\n\n - Typically a hyphen or asterisk is used for the bullet, preceded\n   by a single space, with blank lines in between, but conventions\n   vary here\n\nIf you use an issue tracker, put references to them at the bottom,\nlike this:\n\nResolves: #123\nSee also: #456, #789\n```\n\n**Example:**\n\n```\nfeat(accounts): Add user signup validations\n\nAdd validation constraints for user signup. Require password length to be \nminimum of 6 and contain Alphanumeric characters.\n\n[Done #512345]\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsarscode%2Fgit-style-guide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsarscode%2Fgit-style-guide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsarscode%2Fgit-style-guide/lists"}