{"id":13942523,"url":"https://github.com/LeDuble/Git-Etiquette","last_synced_at":"2025-07-20T06:31:23.825Z","repository":{"id":151488230,"uuid":"397132465","full_name":"LeDuble/Git-Etiquette","owner":"LeDuble","description":"Git Etiquette - Standardized workflow frame for teams and individuals.","archived":false,"fork":false,"pushed_at":"2023-05-29T05:24:21.000Z","size":369,"stargazers_count":17,"open_issues_count":14,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-11-27T12:36:45.910Z","etag":null,"topics":["automation","branching-strategies","cheatsheet","community","documentation","etiquette","git","git-flow","github","github-actions","issue-labels","issue-management","issues","issues-form","organization-management","project-management","project-template","pull-requests","template","workflow-automation"],"latest_commit_sha":null,"homepage":"https://github.com/LeDuble/Git-Etiquette-Template/generate","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc-by-sa-4.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/LeDuble.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":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2021-08-17T06:26:05.000Z","updated_at":"2024-11-18T09:37:06.000Z","dependencies_parsed_at":"2024-04-10T14:53:08.966Z","dependency_job_id":null,"html_url":"https://github.com/LeDuble/Git-Etiquette","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/LeDuble/Git-Etiquette","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LeDuble%2FGit-Etiquette","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LeDuble%2FGit-Etiquette/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LeDuble%2FGit-Etiquette/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LeDuble%2FGit-Etiquette/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/LeDuble","download_url":"https://codeload.github.com/LeDuble/Git-Etiquette/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/LeDuble%2FGit-Etiquette/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":266076350,"owners_count":23872741,"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":["automation","branching-strategies","cheatsheet","community","documentation","etiquette","git","git-flow","github","github-actions","issue-labels","issue-management","issues","issues-form","organization-management","project-management","project-template","pull-requests","template","workflow-automation"],"created_at":"2024-08-08T02:01:55.027Z","updated_at":"2025-07-20T06:31:23.399Z","avatar_url":"https://github.com/LeDuble.png","language":null,"funding_links":[],"categories":["Others"],"sub_categories":[],"readme":"\u003c!-- TITLE / HEADER --\u003e\n\u003ch1 align=\"left\"\u003e\n\u003ca id=\"title\" href=\"#title\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nGit Etiquette\n\u003c/h1\u003e\n\n\u003cp align=\"center\"\u003e\n   \u003cimg height=\"180\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/git-etiquette-banner-no-bg.png\"\u003e\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e \n   \u003cb\u003eStandardized workflow frame for teams and individuals.\u003c/b\u003e\n\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n   \u003ca href=\"https://creativecommons.org/licenses/by-sa/4.0/\"\u003e\n    \u003cimg title=\"License\" src=\"https://img.shields.io/badge/license-CC%20BY--SA%204.0-blue\"\u003e\n   \u003c/a\u003e\n   \u003ca href=\"http://makeapullrequest.com\"\u003e\n    \u003cimg title=\"PRs Welcome\" src=\"https://img.shields.io/badge/PRs-welcome-success\"\u003e\n   \u003c/a\u003e\n   \u003ca href=\"https://github.com/LeDuble/Git-Etiquette/graphs/contributors\"\u003e\n    \u003cimg title=\"Contributors\" src=\"https://img.shields.io/github/contributors/LeDuble/Git-Etiquette\"\u003e\n   \u003c/a\u003e\n   \u003ca href=\"https://github.com/LeDuble/Git-Etiquette\"\u003e\n    \u003cimg title=\"Star on GitHub\" src=\"https://img.shields.io/github/stars/LeDuble/Git-Etiquette.svg?style=social\u0026label=Star\"\u003e\n   \u003c/a\u003e\n\u003c/p\u003e\n\n\u003c!-- Features --\u003e\n\u003ch1\u003e\n\u003ca id=\"feat\" href=\"#feat\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nFeatures\n\u003c/h1\u003e\n\n- **Git strategy for branching**  \n- **Issues, labels and project board automation**    \n- **Git command cheat sheet**\n\n\u003c!-- TABLE OF CONTENTS --\u003e\n\u003ch2\u003e\n\u003ca id=\"table-of-contents\" href=\"#table-of-contents\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nTable of Contents\n\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"#intro\"\u003eIntroduction\u003c/a\u003e\u003c/li\u003e\n\u003c!-- \u003cli\u003e\u003ca href=\"#feat\"\u003eFeatures\u003c/a\u003e\u003c/li\u003e --\u003e\n\u003cli\u003e\u003ca href=\"#start\"\u003eGetting Started\u003c/a\u003e\u003c/li\u003e\n\u003cul\u003e\u003ca href=\"#proj\"\u003e- Project board\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#labe\"\u003e- The labels for issues \u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#issu\"\u003e- Issues forms and pull request template \u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#wfile\"\u003e- Workflow file setup \u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#base\"\u003e- Base tree for repository \u003c/a\u003e\u003c/ul\u003e\n\u003cli\u003e\u003ca href=\"#gtst\"\u003eGit strategy and usage\u003c/a\u003e\u003c/li\u003e\n\u003cul\u003e\u003ca href=\"#bed\"\u003e- Bedrock Rules\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#bran\"\u003e- Branch Strategy\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#form\"\u003e- Formatting Rules\u003c/a\u003e\u003c/ul\u003e\n\u003cli\u003e\u003ca href=\"#usfgit\"\u003eUseful Git Commands\u003c/a\u003e\u003c/li\u003e\n\u003cul\u003e\u003ca href=\"#creabr\"\u003e- How to Create a Branch (via Git)\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#dltbr\"\u003e- Deleting Branches Locally \u0026 Remotely\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#gitig\"\u003e- .gitignore\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#addig\"\u003e- Adding .gitignore into already existing repository\u003c/a\u003e\u003c/ul\u003e\n\u003cul\u003e\u003ca href=\"#mergbr\"\u003e- Merging Branches\u003c/a\u003e\u003c/ul\u003e\n\u003cli\u003e\u003ca href=\"#chtsht\"\u003eCheat Sheet\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#orgs\"\u003eFeatured organizations, teams, and projects that utilize the Git Etiquette\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#ten\"\u003eHow to Contribute\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#nine\"\u003eAuthors\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#eleven\"\u003eLicense\u003c/a\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\n---\n\n\u003c!-- INTRODUCTION --\u003e\n\u003ch1\u003e\n\u003ca id=\"intro\" href=\"#intro\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nIntroduction\n\u003c/h1\u003e\n\nThe main focus of Git Etiquette is to provide a standard way of using Git and project management tools that is shared among developers, which helps to ensure that everyone is on the same page and following the same standardized workflow frame. \n\nBy following the Etiquette, the team can ensure that their workflow will be more consistent, work will be properly documented and their use of the git will be more efficient.\nAdditionally, it provides clear instructions for using Git, which helps to minimize the risk of errors and improves the quality of the work being done.\n\nThe background story for Git Etiquette is that it was started as a personal project to create a unified and coherent workflow for personal use. The goal was to make it easier for others to understand the work being done and navigate the history of the project more easily.\n\nMy team leader was excited about my personal project I was working on and assigned me to write it up so that the rest of the team could benefit from it.\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- Getting started --\u003e\n\u003ch1\u003e\n\u003ca id=\"start\" href=\"#start\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nGetting started \n\u003c/h1\u003e\n\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"#proj\"\u003eProject board\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#labe\"\u003eThe labels for issues \u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#issu\"\u003eIssues forms and pull request template \u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#wfile\"\u003eWorkflow file setup \u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#base\"\u003eBase tree for repository \u003c/a\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\n\u003c!-- Project board --\u003e\n\u003ch2\u003e\n\u003ca id=\"proj\" href=\"#proj\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nProject Board\n\u003c/h2\u003e\nHere's how you setup your project board, which is a crucial part of automation and project management.\n\n\u003cimg align=left width=\"163\" height=\"287\" alt=\"\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/savechanges.png\"\u003e\u003c/img\u003e\n#### Views\nProject views allow you to view the project from different layouts and are located at the top as tabs.\n\nSet up for each view:\nName | Layout | Group | Fields\n--- | --- | --- | ---\n*List view by status* | Table | Status | All, except Milestones\n*Board view* | Board | Default | All, except Milestones, Tracks, Tracked by\n*List all* | Table | Default | All, except Milestones\n\nRemember to save changes!\n\n#### Status\nIn projects, click the three dots in the top right corner, select Settings, then under Custom Fields, click on Status and add the following statuses (including the emojis):\n\u003c!-- * Unassigned ❕\n* Unlabeled ❗ --\u003e\n* **Backlog 📜**\n* **In Progress 🚧**\n* **Ready for Review 🔍**\n* **Done ✔️**\n\nAlso don't forget to remove any default statuses.\n\n#### Example\nYou can view the project board of this repository to get an example of what the project board should look like and how the automation is handled.\n\n\u003ca href=\"https://github.com/users/LeDuble/projects/5/views/1\"\u003eA project board\u003c/a\u003e\n\n(\u003ca href=\"#start\"\u003eback to Getting Started\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- The labels for issues --\u003e\n\u003ch2\u003e\n\u003ca id=\"labe\" href=\"#labe\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nThe labels for issues\n\u003c/h2\u003e\n\n#### Featured labels\n* Labels can either be assigned automatically by the automation or manually by the user. It is best to let the automation handle the assignment of labels marked as \"automatically\" and not add them manually to an issue.\n* when a new issue is opened, it will be automatically assigned the \"Backlog 📜\" label. If an issue is already labeled as \"In Progress 🚧\", you can change the label back to \"Backlog 📜\" if needed.\n\n#### Adding labels to the repository\nYou can add labels by going to the repository, clicking on the \u003ci\u003eIssues\u003c/i\u003e tab, and then clicking on the \u003ci\u003eLabels\u003c/i\u003e button, which is located next to the milestones option, and now you can start copying these labels by clicking on the \u003ci\u003eNew Labels\u003c/i\u003e button.\n\n\u003cimg width=\"386\" height=\"64\" alt=\"\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/labelsteps.jpg\"\u003e\n\n\n#### Organization default repository labels\nIf you plan to use these labels across all of your organization's future repositories, then you can go to your organization's \u003ci\u003esettings\u003c/i\u003e, navigate to the \u003ci\u003erepository\u003c/i\u003e section under \u003ci\u003e\"code, planning, and automation\"\u003c/i\u003e, and click on \u003ci\u003erepository defaults\u003c/i\u003e. Then, you can click on the \u003ci\u003enew label\u003c/i\u003e button and add the labels. These labels will featured in all of organization's future repositories, but will not be added to already existing repositories, so you will need to add them manually to those. \n\nLabel Name | Description | Manually or Automatically | Label / Status Field\n--- | --- | --- | :---:\nDocs 📝 | Changes to documentation only | Manually | Label\nFeat 🆕 | A new feature | Manually | Label\nStyle 🖌️ | Changes to formatting (e.g. the code is missing semicolons) | Manually | Label\nTest ☑️ | Adding/correcting existing tests | Manually | Label\nRefactor 🔁 | A code change which isn't bug fix or adds a feature. It's restructure of the code without changing the functionality | Manually | Label\nBugFix 🐛 | A bug fix | Manually | Label\nChore 👷‍♂️ | Maintenance or change to auxiliary tools | Manually | Label\nAdd ➕ | Adding essentials to the repository (e.g. .gitignore or example files) | Manually | Label\nBackend ⚙️ | When a backend issue is opened, it is automatically given to the issue | Automatically | Label\nFrontend 🖥️ | When a fronted issue is opened, it is automatically given to the issue | Automatically | Label\nDesign 🎨 | When a design issue is opened, it is automatically given to the issue | Automatically | Label\nUnassigned ❕ | Currently nobody has been assigned to it | Automatically | Label\nUnlabeled ❗ | No labels have been added | Automatically | Label\nBacklog 📜 | Tasks that have not yet been started or left unfinished | Both | Both\nIn Progress 🚧 | Currently in the process of being worked on | Manually | Both\nReady for Review 🔍 | A pull request has been created and it is ready for review | Manually | Both\nDone ✔️ | Task has been completed or closed | Manually | Both\n\n* When copying and pasting labels, make sure to include any associated emojis.\n\n(\u003ca href=\"#start\"\u003eback to Getting Started\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- Issues forms and pull request template --\u003e\n\u003ch2\u003e\n\u003ca id=\"issu\" href=\"#issu\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nIssues forms and pull request template\n\u003c/h2\u003e\n\nMake sure to add the issue form files to the `.github/ISSUE_TEMPLATE` folder in your repository, and the pull request template goes to the `.github` folder.\n\nPick them from here:\nIssue forms | Pull request template\n---|---\n\u003ca href=\"https://github.com/LeDuble/Git-Etiquette/blob/main/.github/ISSUE_TEMPLATE/backend-card.yml\"\u003ebackend-card.yml\u003c/a\u003e | \u003ca href=\"https://github.com/LeDuble/Git-Etiquette/blob/main/pull_request_template.md\"\u003epull_request_template.md\u003c/a\u003e\n\u003ca href=\"https://github.com/LeDuble/Git-Etiquette/blob/main/.github/ISSUE_TEMPLATE/design-card.yml\"\u003edesign-card.yml\u003c/a\u003e |\n\u003ca href=\"https://github.com/LeDuble/Git-Etiquette/blob/main/.github/ISSUE_TEMPLATE/frontend-card.yml\"\u003efrontend-card.yml\u003c/a\u003e |\n\u003c!-- \u003ca href=\"\"\u003econfig.yml\u003c/a\u003e | --\u003e\n\nWhen creating an issue, depending on which one you pick, the form will automatically add one of the three labels (Backend ⚙️, Design 🎨, or Frontend 🖥️). For example, if you select a card related to backend development, it will add the \"Backend ⚙️\" label.\n\n   \u003col\u003e\n   \u003cli\u003eOpen a new issue inside the repository.\u003c/li\u003e\n   \u003cli\u003eChoose one of the cards or templates (Backend, Frontend, or Design).\u003c/li\u003e\n   \u003cul\u003e- For example if you choose the backend card, then the Backend ⚙️ label will be added.\u003c/ul\u003e\n   \u003cul\u003e- Backlog 📜 label is always added when opening an issue.\u003c/ul\u003e\n   \u003cli\u003ePick one descriptive label from this list: Docs 📝, Feat 🆕, Style 🖌️, Test ☑️, Refactor 🔁, BugFix 🐛, Chore 👷‍♂️, Add ➕ \u003c/li\u003e\n   \u003cli\u003eyou can add another label from this list: In Progress 🚧, Done ✔️\u003c/li\u003e\n   \u003cul\u003eThe label \"In Progress 🚧\" means that someone is currently working on the issue.\u003c/ul\u003e\n   \u003cul\u003eThe label \"Done ✔️\" indicates that the issue has been completed or closed.\u003c/ul\u003e\n   \u003c/ol\u003e\n\n   ```mermaid\n\n   %%{init: {'themeVariables': { 'fontSize': '20px'}}}%%\n    graph LR;\n        classDef infoboxcolors fill:#fff2cc, color:#000000;\n        classDef firstboxcolors fill:#dae8fc, color:#000000;\n        classDef secondboxcolors fill:#e1d5e7, color:#000000;\n        classDef thirdboxcolors fill:#d5e8d4, color:#000000;\n\n    subgraph Main\n    style Main color:#00000000, fill:#00000000, stroke:#f66, stroke-width:2px, stroke-dasharray:5 5\n    \n    subgraph .\n    style . color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66\n        subgraph 1.\n        style 1. color:#272B30, stroke:#f66, fill:#f8cecc\n    end\n\n        X([Open an issue])--\u003eA[Project];\n        class X infoboxcolors;\n        class A firstboxcolors;\n        end\n    \n    subgraph ..\n    style .. color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66\n        subgraph 2.\n        style 2. color:#272B30, stroke:#f66, fill:#f8cecc\n    end\n\n        A-.-\u003eXX([Choose\u003c/br\u003e a template]);\n        class XX infoboxcolors;\n\n        XX--\u003eB((Backend)) \u0026 C((Frontend)) \u0026 D((Design));\n        class B,C,D secondboxcolors;\n        end\n\n    subgraph ...\n    style ... color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66\n        subgraph 3.\n        style 3. color:#272B30, stroke:#f66, fill:#f8cecc\n    end\n\n        .... -.-\u003eXXX([A more descriptive\u003c/br\u003elabel\u003c/br\u003eis added\u003c/br\u003emanually]);\n        class XXX infoboxcolors;\n        XXX--\u003eE(Docs);\n        XXX--\u003eF(Feat);\n        XXX--\u003eG(Style);\n        XXX--\u003eH(Test);\n        XXX--\u003eI(Refactor);\n        XXX--\u003eJ(Bugfix);\n        XXX--\u003eK(Chore);\n        XXX--\u003eL(Add);\n        XXX--\u003eR(In Progress);\n        XXX--\u003eS(Done);\n        class E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U thirdboxcolors;\n        end\n    \n    subgraph ....\n    style .... color:#00000000, fill:#00000000, stroke-width:3px, stroke:#f66\n        subgraph 3.\n        style 3. color:#272B30, stroke:#f66, fill:#f8cecc\n    end\n\n        Frontend \u0026 Backend \u0026 Design \u0026 Backlog -.- XXXX([These labels\u003c/br\u003ewill be automatically\u003c/br\u003eadded accordingly]);\n        class XXXX infoboxcolors;\n        C--\u003eFrontend(Frontend);\n        B--\u003eBackend(Backend);\n        D--\u003eDesign(Design);\n        C \u0026 B \u0026 D--\u003eBacklog(Backlog);\n        class E,F,G,H,I,J,K,L,M thirdboxcolors;\n        end\n    end\n\n   ```\n   Schema for labeling.\n\n(\u003ca href=\"#start\"\u003eback to Getting Started\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- Workflow file setup --\u003e\n\u003ch2\u003e\n\u003ca id=\"wfile\" href=\"#wfile\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nWorkflow file setup\n\u003c/h2\u003e\n\nVariable | Description | Example Organisation / User specific setting |\n--- | --- | ---\n`username` | | User\n`gh_project_token` | | User\n`organization_name` | | Organisation\n`gh_app_key` | | Organisation\n`gh_app_id` | | Organisation\n`gh_app_installation_id` | | Organisation\n`project_number` | | Both\n`project_portfolio_number` | | Both\n\n### Authentication for user\nCreate a Personal Access Token (PAT)\n1. Let's begin with creating a PAT by going to the \u003ci\u003epersonal settings\u003c/i\u003e. From there, go to \u003ci\u003ethe developer settings\u003c/i\u003e and then click on the \u003ci\u003epersonal access tokens\u003c/i\u003e on the left menu, which opens a menu of two items. Pick the \u003ci\u003etokens (classic)\u003c/i\u003e from the dropdown menu, and then press the button that says \u003ci\u003e\"Generate new token\"\u003c/i\u003e to generate a new token (classic)\n\nFor additional details on creating a PAT, refer to the \u003ca href=\"https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#keeping-your-personal-access-tokens-secure\"\u003edocuments\u003c/a\u003e\n\n2. Select the following scopes (permissions)\n   * \u003cb\u003erepo\u003c/b\u003e - \u003ci\u003eall\u003c/i\u003e\n   * \u003cb\u003eadmin:org\u003c/b\u003e - \u003ci\u003ewrite:org\u003c/i\u003e\n   * \u003cb\u003eadmin:org\u003c/b\u003e - \u003ci\u003eread:org\u003c/i\u003e\n   * \u003cb\u003eproject\u003c/b\u003e - \u003ci\u003eread:project\u003c/i\u003e\n\n3. Save the given token in to your repository secrets and name it as `SECRET_TOKEN` so that the workflow file knows what to look for.\n   \n### Authentication for organisation (via app)\n* Start by creating a Github App under your organization. Follow the instructions in the \u003ca href=\"https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/creating-a-github-app\"\u003edocuments\u003c/a\u003e.\n\n#### App settings\n*  For the newly created Github App, set the following requirements: \n   * Repository permissions (8 in total) \n      * \u003cb\u003eActions\u003c/b\u003e - \u003ci\u003eRead and write\u003c/i\u003e\n      * \u003cb\u003eChecks\u003c/b\u003e - \u003ci\u003eRead and write\u003c/i\u003e\n      * \u003cb\u003eCommit statuses\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n      * \u003cb\u003eContents\u003c/b\u003e - \u003ci\u003eRead and write\u003c/i\u003e\n      * \u003cb\u003eEnvironments\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n      * \u003cb\u003eIssues\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n      * \u003cb\u003eMetadata\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n      * \u003cb\u003ePull requests\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n   * Organization permissions (2 in total)\n      * \u003cb\u003eMembers\u003c/b\u003e - \u003ci\u003eRead only\u003c/i\u003e\n      * \u003cb\u003eProjects\u003c/b\u003e - \u003ci\u003eRead and write\u003c/i\u003e\n   \n   * Check the \u003ca href=\"https://docs.github.com/en/apps/maintaining-github-apps/editing-a-github-apps-permissions\"\u003edocuments\u003c/a\u003e to see how to edit the permissions of the Github App.\n\n* Go to Optional features (in the app) and opt-out from the following setting:\n   * User-to-server token expiration\n* Generate a private key, treat the file like the password and keep it safe.\n\n#### Installing\n* Install the Github App in the organization\n   * To install the GitHub App in your organization, go to your \u003ci\u003eorganization's settings\u003c/i\u003e, navigate to \u003ci\u003eDeveloper settings\u003c/i\u003e, select \u003ci\u003eGitHub Apps\u003c/i\u003e, click \u003ci\u003eedit\u003c/i\u003e next to the app, select \u003ci\u003eInstall App\u003c/i\u003e, and then click \u003ci\u003eInstall\u003c/i\u003e.\n\n#### Secrets\n* To make the \u003ci\u003e\u003cb\u003eprivate key\u003c/b\u003e\u003c/i\u003e, \u003ci\u003e\u003cb\u003ethe GitHub App's installation id\u003c/b\u003e\u003c/i\u003e, and \u003ci\u003e\u003cb\u003ethe App's id\u003c/b\u003e\u003c/i\u003e accessible to all the repositories in the organization for the workflow file, store the private key as `PRIVATE_KEY`, the GitHub App's installation id as `APP_INSTALLATION_ID`, and the app's id as `APP_ID` as secrets in the organization's settings and actions.\n   * \u003ci\u003e\u003cb\u003eThe private key\u003c/b\u003e\u003c/i\u003e can be generated within the app itself, by navigating to the app's settings and selecting the Generate Private Key option.\n   * \u003ci\u003e\u003cb\u003eApp id\u003c/b\u003e\u003c/i\u003e can be found from configuration general page as \u003ci\u003eApp ID\u003c/i\u003e\n   * To find \u003ci\u003e\u003cb\u003ethe app installation id\u003c/b\u003e\u003c/i\u003e, navigate to your organization's settings, select Github Apps, and then select Configure next to the app. The `app installation id` can be found now in the address bar, like this: `https://github.com/organizations/\u003corganization\u003e/settings/installations/\u003cid\u003e`\n\n#### Finding number of project board\n* Go to the project board and then look in the address bar, it should appear like this: `https://github.com/users/\u003cusername\u003e/projects/\u003cnumber\u003e` and for the organization it should appear like this: `https://github.com/orgs/\u003corganizationname\u003e/projects/\u003cnumber\u003e`\n* Project id is necessary for the automation.\n\n(\u003ca href=\"#start\"\u003eback to Getting Started\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n#### Editing the parameters in WFprojects.yml file\nOnly the parameters should be changed that are inside the angle brackets (`\u003c\u003e`). For example, ```username: octocat``` or ```project_number: 1``` (remember to remove anglebrackets).\n\nThese parameters can be found org/user related settings in the WFprojects.yml file and are almost at the beginning of the file. \n\n* User related settings (only edit these).\n```  # ----------------- user related settings (only edit these) ----------------- #\nusername: \u003cusername\u003e\ngh_project_token: ${{ secrets.SECRET_TOKEN }}\nproject_number: \u003cprojectid\u003e\n```\n* Organization related settings.\n``` # ----------------- org related settings (only edit these) ----------------- #\norganization_name: \u003corganization\u003e\ngh_app_key: ${{ secrets.APP_SECRET_KEY }}\ngh_app_id: ${{ secrets.APP_ID }}\ngh_app_installation_id: ${{ secrets.APP_INSTALLATION_ID }}\nproject_number: \u003cprojectid\u003e\n```\n\n\u003c!-- Base tree for repository --\u003e\n\u003ch2\u003e\n\u003ca id=\"base\" href=\"#base\" aria-hidden=\"true\"\u003e\u003c/a\u003e\n\n\nBase tree for repository\n\u003c/h2\u003e\nIn the end the base of the repository should look like this:\n\n```text\n.\n├── .github\n│   ├── CODE_OF_CONDUCT.md\n│   ├── CONTRIBUTING.md\n│   ├── ISSUE_TEMPLATE\n│   │   ├── backend-card.yml\n│   │   ├── design-card.yml\n│   │   ├── frontend-card.yml\n│   │   └── config.yml\n│   ├── workflows\n│   │   └── WFprojects.yaml\n│   └── pull_request_template.md\n├── .gitignore\n└── README.md\n\n3 directories, 10 files\n```\nExcluding .gitignore file. There's topic about .gitignore later in this guide, which I recommend to check out.\n\u003c!-- which you can\nread more about \u003ca href=six\u003ehere\u003c/a\u003e and how to add it. --\u003e\n\n(\u003ca href=\"#start\"\u003eback to Getting Started\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- Git strategy and usage --\u003e\n\u003ch1\u003e\n\u003ca id=\"gtst\" href=\"#gtst\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nGit strategy and usage\n\u003c/h1\u003e\n\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"#bed\"\u003eBedrock Rules\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#bran\"\u003eBranch Strategy\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#form\"\u003eFormatting Rules\u003c/a\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- BEDROCK RULES --\u003e\n\u003ch2\u003e\n\u003ca id=\"bed\" href=\"#bed\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nBedrock Rules\n\u003c/h2\u003e\n\n1. **Pull frequently**\n2. **Push infrequently**  \n3. **Commit frequently**    \n   * Merge \"forward frequently\"\n      * Note: Make sure that your branch doesn’t diverge too much from the original branch \n4. **Create pull requests infrequently**\n   * Productivity is not measured by PRs!\n   * If your code affects others, then make a pull request. So that others who are working on the same project gets the latest feature. \n      * In other hand if it doesn't affect others, then do not make unecessary pull requests for minor things.\n      * Key sentence: Quality Over Quantity \n5. **Always ask if unsure**\n\n(\u003ca href=\"#gtst\"\u003eback to Git Strategy and Usage\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- Branching Strategy --\u003e\n\u003ch2\u003e\n\u003ca id=\"bran\" href=\"#bran\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nBranching Strategy\n\u003c/h2\u003e\n\n\u003cimg align=\"right\" width=\"242\" height=\"622\" alt=\"\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/GitStrategySimplified.png\"\u003e\nThe strategy is based on the Git Flow strategy, where each feature (or issue) is represented by a separate branch. Every new branch created is a feature that is being added or worked for the project. The main branch is the production branch, which is the version that is sent to the customer and is always the working one. The dev branch is where all the feature branches are pull requested to aka merged.\n\nThe actual Git Flow strategy also includes release and hotfix branches, which are not included in this strategy. Additonally, version numbering is missing, which might be added later.\n\n### Strategy guideline\n\n#### Branches\nName | Description\n--- | ---\nmain | A production branch\ndev | A development branch\nfeature branches | Each issue is one feature branch\n#### Merging\n* The merge order is from feature branch to development branch, and then from development branch to main branch. This order ensures that changes are tested in the development branch before they are merged in to the main branch. \n   * Simply said: the merge order is: feature \u003e dev \u003e main.\n* Always open pull request from feature branch to dev branch (never to main!).\n* Each issue equals to one feature which is represented by one feature branch.\n* Always open pull request, instead of merging straight to the branch! This ensures that changes are peer reviewed and any potential problems can be identified before the changes are applied to the branch. Even if the problems were accepted via a pull request, it is still easy to revert back if needed.\n\n#### Naming conventions for the branches\n* In the two next sections, you can find instructions on how to properly format the branches in order to ensure the team is following a consistent workflow and that the branches are properly documented.\n\n#### \n\n(\u003ca href=\"#gtst\"\u003eback to Git Strategy and Usage\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- FORMATTING RULES --\u003e\n\u003ch2\u003e\n\u003ca id=\"form\" href=\"#form\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nFormatting Rules for a Branch (Type/Reference ID/Description)\n\u003c!-- Formatting Rules for a Branch Creation --\u003e\n\u003c/h2\u003e\n\n### 1. Type\n   * **Docs** - Changes to documentation only\n   * **Feat** - A new feature\n   * **Style** - Changes to formatting (e.g. the code is missing semicolons)\n   * **Test** - Adding/correcting existing tests\n   * **Refactor** - A code change which isn't bug fix or adds a feature. It's restructure of the code without changing the functionality\n   * **BugFix** - A bug fix\n   * **Chore** - Maintenance or change to auxiliary tools\n   * **Add** - Adding essentials to the repository (e.g. .gitignore or example files)\n\n### 2. Reference ID\n   Reference the issue from GitHub, Trello or some other agile source. \n   For now use one of the two formats shown below.\n   * Referencing an issue from Github: **__issue(_insert number here_)__** or just **__hashtag + number__** (e.g. **_/issue12/_** or **_/#12/_**)\n   * Referencing from Trello: **__trello(_insert number here_)__** (e.g **_/trello8/_**) \n\n### 3. Description\n   Short Description that is 1-3 words long and separated by hyphens aka \" - \". \n   Briefly describes what is done or worked on.\n\n### Examples\n\n\nGood Examples :+1: | Bad Examples :-1:\n------------ | -------------\n:heavy_check_mark: `add/issue12/gitignore` | :x: `something/bug12/do_S*ame\u003c`\n:heavy_check_mark: `style/8/added-missing-semicolons` | :x: `hi/TeSt/ääliö`\n:heavy_check_mark: `fix/trello1/serializer` | :x: `fiX/TreLlo1/SeRiAlIzeR`\n\n**Note:**\nOnly use allowed special characters which are \" / \" and \" - \" when formatting the branch!\n\n(\u003ca href=\"#gtst\"\u003eback to Git Strategy and Usage\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- USEFUL GIT COMMANDS  --\u003e\n\u003ch1\u003e\n\u003ca id=\"usfgit\" href=\"#usfgit\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nUseful Git Commands\n\u003c/h1\u003e\n\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"#creabr\"\u003eHow to Create a Branch (via Git)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#dltbr\"\u003eDeleting Branches Locally \u0026 Remotely\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#gitig\"\u003e.gitignore\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#addig\"\u003eAdding .gitignore into already existing repository\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#mergbr\"\u003eMerging Branches\u003c/a\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- CREATE A BRANCH --\u003e\n\u003ch2\u003e\n\u003ca id=\"creabr\" href=\"#creabr\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nHow to Create a Branch (via Git)\n\u003c/h2\u003e\n\n* **__`git branch -a`__**\n   * see all available branches in this repository/project.\n* **__`git checkout -b \u003cinsertBranchNameHere\u003e`__**\n   * create a new branch (\"__-b__\" creates and switches to it).\n* **__`git switch \u003cinsertBranchNameHere\u003e`__**\n   * switch between branches.\n\n### adding it to working branch (not master)\n* **__`git add –i`__**\n   * Opens interactive menu and it is used to update index using the current content. \n      * There are alternative ways (e.g. `git add .`) to add changes to staging area but, they are not preferred unless you are experienced git user. Interactive menu gives easy access to control what changes we want to add to staging phase and push forward.\n* **__`git status`__**\n   * Shows which files are tracked by Git and which changes have been staged (which have been not).\n* **__`git restore --staged \u003cinsertFileNameToUnstage\u003e`__**\n   * Note: Incase you added something you don't want to push.\n* **__`git commit -m \"\u003cinsertCommentsHere\u003e\"`__**\n   * Record changes to the repository\n* **__`git push --set-upstream origin \u003cinsertBranchNameHere\u003e`__** \n   * (You can do alias for this)\n\n(\u003ca href=\"#usfgit\"\u003eback to Useful Git Commands\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- MERGING BRANCHES --\u003e\n\u003ch2\u003e\n\u003ca id=\"mergbr\" href=\"#mergbr\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nMerging Branches\n\u003c/h2\u003e\n\nVery important: when merging, make sure that you are on the branch that you want to merge to. You will tell Git basically: \"see those new stuff? Bring them over here.\"\n1. **__`git add -i`__**\n2. **__`git commit -m \"\u003cinsertCommentsHere\u003e\"`__**\n3. **__`git checkout master`__**\n4. **__`git merge \u003cinsertBranchNameHere\u003e --no-ff`__**\n   * Additional command \"**_--no-ff_**\" tells Git that you want to retail all of the comments prior to the merge. Makes tracking easier in the future.\n\nAlways consult before merging directly as it can conflict with others. It is recommended to do pull request instead.\n\n(\u003ca href=\"#usfgit\"\u003eback to Useful Git Commands\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- DELETING BRANCHES --\u003e\n\u003ch2\u003e\n\u003ca id=\"dltbr\" href=\"#dltbr\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nDeleting Branches Locally / Remotely\n\u003c/h2\u003e\n\u003ch3 align=\"left\"\u003eLocally\u003c/h3\u003e\n\n* **__`git branch -d \u003cinsertLocalBranchNameHere\u003e`__** - deletes the merged branch locally (it's not needed anymore!).\n   - \"**_-d_**\" only if the branch has been pushed and merged.\n   - \"**_-D_**\" force the local branch to be deleted, even if it hasn't been pushed or merged yet (important! Always communicate with your team before using force!).\n\u003ch3 align=\"left\"\u003eRemotely\u003c/h3\u003e\n\n* Or use this **__`git push origin --delete \u003cinsertRemoteBranchNameHere\u003e`__** to remove remote branch.\n\n(\u003ca href=\"#usfgit\"\u003eback to Useful Git Commands\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- .GITIGNORE --\u003e\n\u003ch2\u003e\n\u003ca id=\"gitig\" href=\"#gitig\" aria-hidden=\"true\"\u003e\u003c/a\u003e\n.gitignore\n\u003c/h2\u003e\n\nGitignore is essential part of the repository and workflow. It prevents __unnecessary files__ (e.g. large binary files which makes pushing to github very slow) and __secret files__ (e.g. file that includes password or other crucial information) being added to the repository.\n\n* https://gitignore.io - on this page you will find ready-made .gitignore templates that you can use in your projects.\n\n(\u003ca href=\"#usfgit\"\u003eback to Useful Git Commands\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n\u003c!-- ADDING .GITIGNORE --\u003e\n\u003ch2\u003e\n\u003ca id=\"addig\" href=\"#addig\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nAdding .gitignore into already existing repository\n\u003c/h2\u003e\n\nWhen attempting to ignore a file (or files) that's already tracked in the repository, then do this:\n\n1. Commit all changes\n2. Removes any changed files from the index (staging phase).\n   * **__`git rm -r --cached .`__**\n      - \"**_rm_**\" - remove command\n      - \"**_-r_**\" - allow recursive removal\n      - \"**_-cached_**\" - only remove files from the index. Your files will still be there.\n      - \"**_._**\" indicates all files will be untracked. Specific file with \"git rm -r foo.txt\"\n   * With this command we untrack all of the files that have already been added to the repository. **Tl:dr** stop tracking but not delete from the system.\n3. Add .gitignore file\n4. Re-add everything\n   * **__`git add .`__**\n5. Commit \n   * **__`git commit -m \"\u003cinsertCommentsHere\u003e\"`__**\n6. Last step: **__`git push`__**\n\nBecaution here as this will DELETE the file (or files) that is specified in the .gitignore from the github repository.\n\n(\u003ca href=\"#usfgit\"\u003eback to Useful Git Commands\u003c/a\u003e)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- CHEAT SHEET --\u003e\n\u003ch2\u003e\n\u003ca id=\"chtsht\" href=\"#chtsht\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nCheat Sheet\n\u003c/h2\u003e\n\n### :large_orange_diamond: \u003ca href=\"#three\"\u003eCreating a branch\u003c/a\u003e\nCommand | Description | Frequently used?\n------------ | ------------ | :------------:\n`git pull` | Before starting a pull command, it is important to make sure that your working copy is clean and free of any uncommitted local changes. To accomplish this, you can use git's Stash feature to save your local changes temporarily so that they are not overwritten when you pull. This will ensure that any changes you make to the repository are safe and secure. |\n`git branch -a` | See all available branches | :+1:\n`git checkout -b \u003cinsert example: chore/#12/gitignore\u003e` | Create a new branch | :wavy_dash:\n`git switch \u003cinsertBranchNameHere\u003e` | Switch between branches | :+1:\n\n### :large_blue_diamond: \u003ca href=\"#three\"\u003eAdding files to a branch (not master)\u003c/a\u003e\nCommand | Description | Frequently used?\n------------ | ------------ | :------------:\n`git add -i` | Interactive menu | :+1:\n`git status` | Files tracked by Git | :+1:\n`git restore --staged \u003cinsertFileNameToUnstage\u003e` | Unstage unwanted file(s) | :wavy_dash:\n`git commit -m \"\u003cinsertCommentsHere\u003e\"` | Record changes to the \u003c/br\u003erepository | :+1:\n`git push --set-upstream origin \u003cinsertBranchNameHere\u003e` | Push staged files in to \u003c/br\u003ea branch | :+1:\n\n### :red_square: \u003ca href=\"#five\"\u003eDeleting branches\u003c/a\u003e\nCommand | Description | Frequently used?\n------------ | ------------ | :------------:\n`git branch -d \u003cinsertLocalBranchNameHere\u003e` | Delete local branch | :wavy_dash:\n`git push origin --delete \u003cinsertRemoteBranchNameHere\u003e` | Delete remote branch | :wavy_dash:\n\n### :white_medium_square: \u003ca href=\"#four\"\u003eMerging branches\u003c/a\u003e\nnote: merging directly to master or main is not generally recommended, always do a pull request! ! !\nCommand | Description | Frequently used?\n------------ | ------------ | :------------:\n`git add -i` | Interactive menu | :+1:\n`git commit -m \"\u003cinsertCommentsHere\u003e\"` | Record changes to the repository | :+1:\n`git switch master` | Switch to master | :+1:\n`git merge \u003cinsertBranchNameHere\u003e --no-ff` | Merges a branch into master | :-1:\n\n### Git Flow Strategy Cheat Sheet as in schema\n[![GitFlow](https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/GitStrategyCheatSheet.png)](https://creativecommons.org/licenses/by-sa/4.0/)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- EXAMPLES --\u003e\n\u003ch2\u003e\n\u003ca id=\"orgs\" href=\"#orgs\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nFeatured organizations, teams, and projects that utilize the Git Etiquette\n\u003c/h2\u003e\n\n| \u003ca href=https://github.com/VirittamoHelsinki\u003eVirittämö Helsinki\u003c/a\u003e | \u003ca href=https://github.com/VirittamoHelsinki/aava-backend\u003eAava\u003c/a\u003e\n:-------------------------:|:-------------------------:|\n\u003cimg width=\"200\" height=\"200\" alt=\"\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/logohkv.jpg\"\u003e | \u003cimg width=\"200\" height=\"200\" alt=\"\" src=\"https://github.com/LeDuble/Git-Etiquette/blob/main/imgs/logos_tms_orgs/aava.png\"\u003e\n\n\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- HOW TO CONTRIBUTE --\u003e\n\u003ch2\u003e\n\u003ca id=\"ten\" href=\"#ten\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nHow to Contribute\n\u003c/h2\u003e\n\n[![Contributors](https://img.shields.io/github/contributors/LeDuble/Git-Etiquette)](https://github.com/LeDuble/Git-Etiquette/graphs/contributors)\n\n1. Clone repository and create a new branch: **__`git checkout https://github.com/LeDuble/Git-Etiquette.git -b \u003cinsertBranchNameHere\u003e`__**\n2. Add changes to your branch\n3. Create a Pull Request with descriptive text.\n4. Leave a star :star_struck:\n\nFeed back and suggestions are welcome! \n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- AUTHOR --\u003e\n\u003ch2\u003e\n\u003ca id=\"nine\" href=\"#nine\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nAuthor\n\u003c/h2\u003e\n\n* [LeDuble](https://github.com/LeDuble/)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)\n\n---\n\n\u003c!-- LICENSE --\u003e\n\u003ch2\u003e\n\u003ca id=\"eleven\" href=\"#eleven\" aria-hidden=\"true\"\u003e\u003c/a\u003e\nLicense\n\u003c/h2\u003e\n\n[![License](https://img.shields.io/badge/license-CC%20BY--SA%204.0-blue)](https://creativecommons.org/licenses/by-sa/4.0/)\n\nYou can read the full license [here](https://github.com/LeDuble/Git-Etiquette/blob/master/LICENSE.md)\n\n(\u003ca href=\"#table-of-contents\"\u003eback to top\u003c/a\u003e)","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FLeDuble%2FGit-Etiquette","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FLeDuble%2FGit-Etiquette","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FLeDuble%2FGit-Etiquette/lists"}