Mastering Git with Conventional Commits π
Git is a cornerstone of modern software development, and committing code is a daily routine for developers. But not all commits are created equal! Without consistent commit messages, projects can quickly become hard to navigate. Enter Conventional Commitsβa standardized way to write commit messages that are clear, structured, and meaningful.
Git & GitHub
Git and GitHub, while closely related, serve different purposes in software development. Git is a distributed version control system (VCS) that operates locally, allowing developers to track changes, collaborate, and maintain a history of code modifications without requiring an internet connection. In contrast, GitHub is a cloud-based platform built on Git, providing a graphical interface and additional tools for remote collaboration. While Git focuses on managing version control with commands like commit
, branch
, and merge
, GitHub enhances teamwork by offering features like pull requests, issue tracking, project boards, and continuous integration through GitHub Actions. Git is free, open-source, and independent of any platform, whereas GitHub hosts repositories and enables streamlined collaboration. In essence, Git is the core tool for version control, while GitHub acts as an accessible, feature-rich environment for project hosting and teamwork.
What Are Conventional Commits?
Conventional Commits is a lightweight specification for writing commit messages. It provides a clear format that helps both humans and tools understand the purpose of a commit. Here's the structure:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Why Use Conventional Commits? π οΈ
- Improved Communication: Clear commit messages make it easier for team members to understand changes.
-
Automated Changelogs: Tools like
standard-version
andsemantic-release
can generate changelogs automatically. -
Semantic Versioning: Commit messages help determine whether a change is a
major
,minor
, orpatch
update. - Enforced Standards: Ensures consistency in contributions across teams and repositories.
Commit Types π
Here are the commonly used types in Conventional Commits:
- feat: Introduces a new feature.
- fix: Patches a bug.
- docs: Updates documentation only.
- style: Changes that do not affect the codeβs functionality (e.g., formatting, missing semicolons).
- refactor: Code changes that neither fix a bug nor add a feature.
- test: Adds or updates tests.
- chore: Changes to the build process or auxiliary tools (e.g., dependencies).
Example Commit Messages
- Feature:
feat(auth): add login functionality
- Bug Fix:
fix(api): resolve null pointer issue in fetch method
- Documentation:
docs(readme): add setup instructions
- Breaking Change:
feat(user): remove deprecated endpoints
BREAKING CHANGE: The `/v1/users` endpoint is no longer supported.
Getting Started with Conventional Commits
- Install Linting Tools: Use tools like Commitlint to enforce commit message formats.
npm install --save-dev @commitlint/{config-conventional,cli}
- Use Commitizen: Simplify the process of writing commit messages with Commitizen.
npx commitizen init cz-conventional-changelog --save-dev --save-exact
-
Automate Changelogs:
Combine Conventional Commits with tools like
semantic-release
to automate versioning and changelogs.
Using My Own Script
Here I made a simple push script with bash
to write conventional commit on GitHub.
#!/bin/bash
# Author : ESHAN ROY
# Author URI : https://eshanized.github.io
# NOTE : Run at your own risk!
# Define the conventional commit types with new emojis
TYPES=("π feat" "π fix" "π docs" "β¨ style" "π refactor" "β‘οΈ perf" "π¬ test" "π§ build" "π€ ci" "π§Ή chore" "βͺ revert")
# Function to display an error and exit
error_exit() {
echo -e "\033[1;31m[ERROR]\033[0m $1"
exit 1
}
# Ensure the script is run in a Git repository
git rev-parse --is-inside-work-tree > /dev/null 2>&1 || error_exit "This is not a Git repository."
# Get the current branch name
branch=$(git rev-parse --abbrev-ref HEAD)
# Pull the latest changes from the remote repository
echo "Pulling latest changes from remote branch '$branch'..."
git pull origin "$branch" || error_exit "Failed to pull changes from the remote repository. Please resolve any conflicts manually."
# Prompt the user to select a commit type
echo "Select a commit type:"
select type in "${TYPES[@]}"; do
if [[ -n "$type" ]]; then
break
else
echo "Invalid selection. Please try again."
fi
done
# Extract the commit type and emoji from the selection
type_emoji=${type}
type=${type_emoji#* }
emoji=${type_emoji% *}
# Prompt the user to enter a scope (optional)
read -p "Enter a scope (optional): " scope
scope_part=""
if [ -n "$scope" ]; then
scope_part="($scope)"
fi
# Prompt the user to enter a short description
read -p "Enter a short description: " desc
if [ -z "$desc" ]; then
error_exit "A short description is required!"
fi
# Prompt the user to enter a longer description (optional)
read -p "Enter a longer description (optional): " long_desc
# Create the commit message
commit_msg="$emoji $type$scope_part: $desc"
# If a longer description was provided, add it to the commit message
if [ -n "$long_desc" ]; then
commit_msg+="
$long_desc"
fi
# Print the commit message to the console
echo -e "\nCommit message:"
echo -e "\033[1;36m$commit_msg\033[0m"
# Confirm before committing
read -p "Do you want to proceed with this commit? (y/n): " confirm
if [[ "$confirm" != "y" && "$confirm" != "Y" ]]; then
echo "Commit aborted."
exit 0
fi
# Stage all changes
git add .
# Commit the changes with the conventional commit message
if git commit -m "$commit_msg"; then
echo -e "\033[1;32mCommit successful!\033[0m"
else
error_exit "Commit failed."
fi
# Push the changes to the remote repository
echo "Pushing changes to remote branch '$branch'..."
if git push origin "$branch"; then
echo -e "\033[1;32mChanges pushed to remote branch '$branch'.\033[0m"
else
error_exit "Push failed. Please check your connection or branch permissions."
fi
It will first pull any changes then do commit.
Last Words
Adopting Conventional Commits streamlines your development workflow and improves collaboration. By enforcing consistency and leveraging tools for automation, you can focus more on coding and less on managing version histories.
Start using Conventional Commits today and transform how your team works with Git! π
Top comments (0)