└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # A Conventional Commit Cheat Sheet 2 | 3 | An easy-to-follow guide that helps you become a 🚀 better developer 🚀 by mastering 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 | By adopting Conventional Commits, it enhances your communication skills with clear, structured commit messages, helping you focus on the impact of your changes. This not only improves the way you work but also leads to smoother project management and better code quality, making collaboration more efficient. 9 | 10 | ## How to use Conventional Commits? 11 | 12 | ### 1. **Commit messages using `git commit` in the Terminal** 13 | 14 | You will use the `git commit` command in your terminal when you make changes to your code and want to commit them using **Conventional Commits**. The key is to follow the **Conventional Commit** format for your commit messages. 15 | 16 | #### Example Command: 17 | In your terminal, run the following: 18 | 19 | 20 | git commit -m "feat(booking): add Update Booking feature" 21 | 22 | ## Steps to Commit in the Terminal 23 | 24 | 1. **Make Changes**: Modify your files as needed. 25 | 26 | 2. **Stage Your Changes**: Add your modified files to the staging area. 27 | git add 28 | Or to add all changed files at once: 29 | git add . 30 | 31 | 3. **Commit with Conventional Commit Message**: After staging the changes, use the following command to commit: 32 | git commit -m "feat(DataTable): add no data found message" 33 | 34 | 4. **Push the Changes**: Push your commits to the remote repository. 35 | git push 36 | Or if you are pushing to a specific branch: 37 | git push origin 38 | 39 | 40 | 41 | ## 🚀 Basic Structure 42 | 43 | Each commit message follows this structure: 44 | 45 | - **type**: Describes the change (e.g., `feat`, `fix`, `chore`) 46 | - **scope**: Optional. Refers to the area of the project being affected (e.g., `api`, `frontend`) 47 | - **description**: A short description of the change. 48 | 49 | --- 50 | 51 | ## 📋 Types of Commit 52 | 53 | 1. **feat**: A new feature for the system 54 | Example: `feat(Booking): add Update Booking feature` 55 | 56 | 2. **fix**: A bug fix for the system 57 | Example: `fix(DataTable): resolve issue with DataTable filter state` 58 | 59 | 3. **chore**: Routine tasks like maintenance or updating dependencies 60 | Example: `chore(deps): update antd to version 5.22.7` 61 | 62 | 4. **docs**: Documentation updates 63 | Example: `docs(readme): update installation instructions` 64 | 65 | 5. **style**: Changes related to code style (e.g., formatting, missing semi-colons) 66 | Example: `style(DataTable): fix item alignment in CSS` 67 | 68 | 6. **refactor**: Code change that neither fixes a bug nor adds a feature 69 | Example: `refactor(usePageParams): simplify usePageParams hook` 70 | 71 | 7. **test**: Adding or updating tests 72 | Example: `test(usePageParams): add unit tests for usePageParams hook` 73 | 74 | 8. **build**: Changes that affect the build system or external dependencies 75 | Example: `build(vite): add vite config for production build` 76 | 77 | 9. **ci**: Continuous integration-related changes 78 | Example: `ci(bitbucket): update CI config for deployment pipeline` 79 | 80 | 81 | ## 🧑‍💻 Learn More 82 | 83 | For a deeper understanding of Conventional Commits, check out the official documentation: [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). 84 | 85 | --- 86 | 87 | ## 💡 Tips 88 | 89 | - Keep your messages clear and concise. 90 | - Use the type that best represents the change you made. 91 | 92 | ## Who 93 | 94 | Written ❤️ by [SaroarShahan](https://www.shahansdiary.com/), made better by you. --------------------------------------------------------------------------------