Git Best Practices: A Guide for Solo and Pair Developers

Git Best Practices: A Guide for Solo and Pair Developers

  1. #git
  2. #github
Raff Bougherara

Raff Bougherara

Software Enthusiast

Git is essential in modern software development, not just for large teams but also for solo developers and pairs working on projects. Following Git best practices even in small teams demonstrates your professionalism and readiness for collaboration. This guide will walk through how one or two developers can simulate team-based Git workflows to ensure structure, quality, and readiness for scaling.

Importance of Git Best Practices

Following Git best practices ensures that:

  • Code remains clean and maintainable.
  • Team members (or future collaborators) can track changes and understand project progress.
  • Merging and releasing code is systematic, reducing the risk of errors.

Even as a solo or pair developer, adhering to these best practices shows foresight in structuring your project for long-term scalability.

Simulating a Team Environment

When working in small teams, it can be tempting to work directly on the main branch, skipping many steps that larger teams follow. However, this introduces risks, such as difficult rollbacks or poorly documented changes. Here's how to simulate a multi-developer environment with Git, even with only one or two developers.

1. Establish a Clear Branching Strategy

Start by defining a clear branching strategy. For small teams, a straightforward approach is using three key branches:

  • Main (Production): This is the branch that always contains the latest stable code. Only merge into main when you're ready to release.
  • Development (Dev): A branch where new features and fixes are consolidated before being considered for the production environment.
  • Feature Branches: Each feature or bug fix should be developed in its own branch, derived from dev.

2. Working with Git Commands

To bring this structure to life, let's break down the Git commands you'll be using. Below is a step-by-step guide on how to create branches and simulate a structured workflow.

a) Create a Development Branch from Main

Before diving into feature work, always create and use a dev branch. This branch will act as a staging ground for your work before it's merged into main.

# Switch to the main branch
git checkout main
 
# Ensure the main branch is up to date
git pull origin main
 
# Create a new dev branch
git checkout -b dev
 
# Push the dev branch to the remote repository
git push -u origin dev

b) Create Feature Branches from Dev

Each feature should be developed in its own branch. This ensures that you can work independently of other ongoing work and merge changes incrementally.

# Switch to the dev branch
git checkout dev
 
# Ensure the dev branch is up to date
git pull origin dev
 
# Create a feature branch
git checkout -b feature/your-feature-name
 
# Push the feature branch to the remote repository
git push -u origin feature/your-feature-name

c) Work on the Feature Branch

During development, you will regularly commit and push your changes to the feature branch. Always use meaningful commit messages that describe the changes clearly.

# Stage your changes
git add .
 
# Commit with a descriptive message
git commit -m "Add a descriptive commit message"
 
# Push your changes to the remote feature branch
git push origin feature/your-feature-name

d) Merge Feature Branch into Dev via Pull Request (PR)

Once your feature is complete, it's time to merge it into the dev branch. Instead of merging directly, create a Pull Request (PR) on GitHub or your preferred platform. This simulates a review process, which is crucial for maintaining quality.

  1. Push all changes to the feature branch.
  2. On GitHub, create a PR to merge feature/your-feature-name into dev.
  3. Review the code (even if it's just you—it's good practice).
  4. Once satisfied, merge the PR.

e) Keep Dev Branch Updated

After merging your feature into dev, always ensure your local dev branch is up to date.

# Switch to the dev branch
git checkout dev
 
# Pull the latest changes
git pull origin dev

f) Merge Dev into Main When Ready for Release

When you're ready to release a new version, the dev branch will be merged into main. Again, simulate a review process by creating a PR from dev to main.

  1. On GitHub, create a PR from dev to main.
  2. Merge the PR once all checks and reviews are completed.

g) Update the Main Branch

After the PR is merged, ensure your local main branch is up to date.

This approach doesn't just help with your current project; it prepares you for future growth, whether you're joining a larger team or scaling your own development efforts.

Commands Summary

// Switch to the main branch
git checkout main
 
// Pull the latest changes from main
git pull origin main
 
// Create dev branch from main
git checkout main
git pull origin main
git checkout -b dev
git push -u origin dev
 
// Create feature branch from dev
git checkout dev
git pull origin dev
git checkout -b feature/your-feature-name
git push -u origin feature/your-feature-name
 
// Work on feature branch
git add .
git commit -m "Add a descriptive commit message"
git push origin feature/your-feature-name
 
// Merge feature branch into dev via PR on GitHub
 
// Update dev branch
git checkout dev
git pull origin dev
 
// Merge dev into main via PR on GitHub
 
// Update main branch
git checkout main
git pull origin main