DEV Community

Cover image for Mastering Git with Conventional Commits 🌟
Eshan Roy (eshanized)
Eshan Roy (eshanized)

Posted on

Mastering Git with Conventional Commits 🌟

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)]
Enter fullscreen mode Exit fullscreen mode

Why Use Conventional Commits? πŸ› οΈ

  • Improved Communication: Clear commit messages make it easier for team members to understand changes.
  • Automated Changelogs: Tools like standard-version and semantic-release can generate changelogs automatically.
  • Semantic Versioning: Commit messages help determine whether a change is a major, minor, or patch 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
Enter fullscreen mode Exit fullscreen mode
  • Bug Fix:
  fix(api): resolve null pointer issue in fetch method
Enter fullscreen mode Exit fullscreen mode
  • Documentation:
  docs(readme): add setup instructions
Enter fullscreen mode Exit fullscreen mode
  • Breaking Change:
  feat(user): remove deprecated endpoints

  BREAKING CHANGE: The `/v1/users` endpoint is no longer supported.
Enter fullscreen mode Exit fullscreen mode

Getting Started with Conventional Commits

  1. Install Linting Tools: Use tools like Commitlint to enforce commit message formats.
   npm install --save-dev @commitlint/{config-conventional,cli}
Enter fullscreen mode Exit fullscreen mode
  1. Use Commitizen: Simplify the process of writing commit messages with Commitizen.
   npx commitizen init cz-conventional-changelog --save-dev --save-exact
Enter fullscreen mode Exit fullscreen mode
  1. 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
Enter fullscreen mode Exit fullscreen mode

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)