├── FUNDING.yml ├── Conventional Commit - AninoDev.pdf └── README.md /FUNDING.yml: -------------------------------------------------------------------------------- 1 | github: [BryanLomerio] 2 | -------------------------------------------------------------------------------- /Conventional Commit - AninoDev.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BryanLomerio/conventional-commit-cheatsheet/HEAD/Conventional Commit - AninoDev.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Conventional Commit Cheat Sheet 2 | 3 | A simple guide to help you understand and apply the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) standard for versioning in your projects. 4 | 5 | --- 6 | ### Helps You Be a Better Developer 7 | 8 | Adopting Conventional Commits improves your communication skills by encouraging clear and organized commit messages. It helps you focus on your changes and their impact, making it easier to manage projects and collaborate effectively. 9 | 10 | 11 | ## 🚀 How to Use Conventional Commits in Your Git Workflow 12 | 13 | ### 1. **Commit Messages Using `git commit` in the Terminal** 14 | 15 | When you make changes to your code and want to commit them using **Conventional Commits**, you'll use the `git commit` command in your terminal. The key is to follow the **Conventional Commit** format for your commit messages. 16 | 17 | #### Example Command: 18 | In your terminal, run the following: 19 | 20 | 21 | git commit -m "feat(auth): add Google login feature" 22 | 23 | ## Steps to Commit in the Terminal 24 | 25 | 1. **Make Changes**: Modify your files as needed. 26 | 27 | 2. **Stage Your Changes**: Add your modified files to the staging area. 28 | git add 29 | Or to add all changed files at once: 30 | git add . 31 | 32 | 3. **Commit with Conventional Commit Message**: After staging the changes, use the following command to commit: 33 | git commit -m "feat(button): add rounded corners" 34 | 35 | 4. **Push the Changes**: Push your commits to the remote repository. 36 | git push 37 | Or if you are pushing to a specific branch: 38 | git push origin 39 | 40 | 41 | 42 | ## 🚀 Basic Structure 43 | 44 | Each commit message follows this structure: 45 | 46 | - **type**: Describes the change (e.g., `feat`, `fix`, `chore`) 47 | - **scope**: Optional. Refers to the area of the project being affected (e.g., `api`, `frontend`) 48 | - **description**: A short description of the change. 49 | 50 | --- 51 | 52 | ## 📋 Types of Commit 53 | 54 | 1. **feat**: A new feature for the user or system 55 | Example: `feat(auth): add Google login feature` 56 | 57 | 2. **fix**: A bug fix for the user or system 58 | Example: `fix(button): resolve issue with button hover state` 59 | 60 | 3. **chore**: Routine tasks like maintenance or updating dependencies 61 | Example: `chore(deps): update react to version 17.0.2` 62 | 63 | 4. **docs**: Documentation updates 64 | Example: `docs(readme): update installation instructions` 65 | 66 | 5. **style**: Changes related to code style (e.g., formatting, missing semi-colons) 67 | Example: `style(button): fix button alignment in CSS` 68 | 69 | 6. **refactor**: Code change that neither fixes a bug nor adds a feature 70 | Example: `refactor(auth): simplify login form validation logic` 71 | 72 | 7. **test**: Adding or updating tests 73 | Example: `test(auth): add unit tests for login function` 74 | 75 | 8. **build**: Changes that affect the build system or external dependencies 76 | Example: `build(webpack): add webpack config for production build` 77 | 78 | 9. **ci**: Continuous integration-related changes 79 | Example: `ci(gitlab): update CI config for deployment pipeline` 80 | 81 | 10. **perf**: Code changes that improve performance 82 | Example: `perf(api): optimize database queries for faster responses` 83 | 84 | 11. **env**: Changes related to environment setup or configuration 85 | Example: `env(docker): update Dockerfile for staging environment` 86 | 87 | 12. **sec**: Security fixes or improvements 88 | Example: `sec(auth): add encryption for user passwords` 89 | 90 | 13. **config**: Changes to configuration files 91 | Example: `config: update .eslint rules for stricter code checks` 92 | 93 | 14. **api**: Updates to API contracts or integrations 94 | Example: `api(user): add new endpoint for user profile updates` 95 | 96 | ## Additional Commit Types 97 | 98 | **revert**: Reverts a previous commit 99 | 100 | Example: revert(auth): rollback Google login feature 101 | 102 | **merge**: Indicates a merge commit 103 | 104 | Example: merge: branch 'feature/auth' into 'main' 105 | 106 | **deps**: Dependency-specific updates 107 | 108 | Example: deps: bump axios from 0.21.1 to 0.24.0 109 | 110 | **design**: UI or UX improvements 111 | 112 | Example: design(button): update hover effect 113 | 114 | 115 | ## 🧑‍💻 Learn More 116 | 117 | For a deeper understanding of Conventional Commits, check out the official documentation: [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). 118 | 119 | --- 120 | 121 | ## 💡 Tips 122 | 123 | - Keep your messages clear and concise. 124 | - Use the type that best represents the change you made. 125 | --------------------------------------------------------------------------------