Git and GitHub are essential tools for software development, yet many beginners avoid using them properly due to concerns about making mistakes. They worry about accidentally deleting production code, pushing secrets, or exposing poorly written code. However, the real problems that emerge are less dramatic but far more damaging: messy commit histories, abandoned branches, and a lack of context.
This guide outlines simple, reliable practices that keep your workflow clean, predictable, and professional.
Essential Commands to Stay in Control
Git provides numerous commands to check your repository status, and running them causes no harm. In fact, you should develop a habit of using them frequently:
1. git status
- The most important command, use it obsessively whenever you can.
- Shows your current branch, what has changed, which files are added, and how your commits compare to the remote origin.
2. git pull
- Generally safe to run at any time, especially before starting a new task.
3. git diff
- Useful for reviewing your unstaged changes.
4. git log
- Useful for reviewing the commit history in your local repository.
Starting with a new Feature
When beginning a new feature, first ensure everything is up to date:
git status # Ensure you're on the main branch
If you’re not on the main branch, switch to it:
git checkout main
Then continue with:
git pull
# Output example:
# remote: Enumerating objects: 3, done.
# ...
# From github.com:repo/project
# a3c912d..e71b4ac main -> origin/main
# Updating a3c912d..e71b4ac
# Fast-forward
# README.md | 4 +++-
# 1 file changed, 3 insertions(+), 1 deletion(-)
git pull # Run again to confirm
# Already up to date.
git log # Optional, to check the latest commits in your local history
git checkout -b a-new-branch-with-a-unique-name # -b to create a new branch
git status # Confirm you're on the new branch
You’re now ready to start coding.
Name your Branches Clearly
Avoid generic names like refactoring, ui_update, or bug_fix.
Branch names should aim to be:
- Informative: Clearly communicate the purpose
- Unique: Prevent accidental conflicts with existing branches
A few good examples of branch names:
fixing-bug-payment-timeout-using-redisfeature/add-user-profile-with-updated-fieldstask-123--fix-db-connection-issue
If available, include the ticket/task number in the branch to ensure uniqueness and improve traceability.
Commit and Push Frequently to Your Branch
New developers hesitate to push code for various reasons:
- the code isn’t working yet
- they’re hiding unfinished work, or
- they fear accidental merges.
However, pushing frequently to a feature branch is exactly what it’s designed for.
Here’s how to do it:
git status # Ensure you're on the correct branch
git add app/config api/src README.md # Add only the files you want
git status # Verify what's staged (colored display)
git commit -m "A Good Commit Message"
git push -u origin HEAD
Tip: If you are on the correct branch git push -u origin HEAD will always work, no need to copy and paste the specific branch name.
After pushing, create a Pull Request (PR) immediately:
New developers assume a PR should only be created when the work is finished. This is incorrect. Opening a PR early provides several benefits:
- A clear, visual summary of all ongoing changes
- An easy way to track progress as you develop
PRs are not a sign of completion.
In fact, most major Git platforms (GitHub, Azure Repos, etc.) offer Draft PRs to prevent accidental merges and to signal that the work is still in progress.
Option to convert a PR to a Draft PR in Github
Option to Create a Draft PR in Azure DevOps
Avoid adding all files to the staging area
Blindly adding everything with git add . risks pushing:
- OS-specific hidden files like .DS_Store
- Temporary artifacts
- Editor swap files
Instead, intentionally add specific files to the staging area:
git add app/config app/utils api/src README.md
However, as a long term solution .gitignore should be used to avoid staging any unwanted files or folders.
Even with a well-maintained .gitignore, make it a habit to add specific files deliberately rather than relying on git add ..
Closing and Merging the PR
Write Clear, Informative Commit Messages
When it’s time to close the PR, the final commit message must be clean and informative. Individual commit messages on the branch won’t appear in the main history, so focus on the PR’s merge message.
A Good Commit Message explains what changed and why. For example:
- Bad: “UI changes”
- Better: “Update to hide unused sidebar buttons to simplify UI”
Tip: Git platforms like GitHub auto-generate merge commit messages and automatically reference PRs using #<number>, which helps maintain a searchable history of closed PRs.
Squash and Merge for Cleaner History
When merging a pull request, use Squash and Merge.
Benefits of Squashing and Merging:
- Your main branch history remains readable, each feature appears as a single commit.
- Individual features are easier to revert if needed by just reverting a single squashed commit.
- Developers can commit frequently on their branch without worrying about cluttering the main branch’s commit history.
Delete the Feature Branch After Merging
After a PR is merged:
- Delete the feature branch immediately.
Tools like GitHub and Azure Repos retain the PR history, so nothing is lost.
GitHub lets you know that a branch can be safely deleted
Azure Repos recommeds to delete the source branch when merging a PR
Ideally, only the main branch and active work-in-progress branches should remain in the repository. This keeps the repository clean and prevents confusion by having abandoned branches.
Hope this guide helps.
If you’d like to explore more advanced Git concepts, workflows, and best practices, you can read my Guide for Professional Developers.