1. Commits

Your commits should be descriptive, meaning they should have a subject line and a description.

The commits should also be specific, that is, code changes that are related are committed together. One might be tempted to write a lot of code and then commit them in a single batch. This makes code changes confusing as the subject and description will not catch everything that changed.

About the subject

  • Subject line should not be longer than 70 characters as it is just a summary of what changed
  • It should be in active voice e.g rename functions with prefix

The description

  • begins one empty line below the subject
  • should describe what changed and why
  • should provide any warnings, for example, what might break

Staging selectively

If you make many changes to the code and want to stage only a few of files to follow the convention of committing related changes, you can specify the files to stage by passing the file names or wilcards to git add command.

Command Description
git add index.html Stage index.html file, where index.html is in the current directory
git add -p index.html Stage index.html in patches, you will be prompted to choose to add or ignore chunks of the file

Committing staged files

To confirm you have staged the correct files, do git status and check the green list of files. If you are satisfied, do git commit and then enter the subject and description in the editor window that pops up and confirm.

Commit history

To check commit history, run git log.

2. Branching

There are various conventions as far as git branching goes. The following are the common branching conventions.

Branching Conventions

Mainline Development Model

This carries the famous mantra, “Always be integrating”. Features:

  • few branches
  • relatively small commits
  • high quality testing and QA standards

The consequence of this convention is that code is quickly integrated to the main branch.

State, Release, and Feature Branches Model

  • Different types of branches
  • Fulfil different types of jobs

Long-Running vs Short-Lived Branches

Long-Running Branches

Examples are: main, develop, staging etc

  • exist throughout project lifetime
  • often mirror stages of development cycle
  • common convention followed is that no direct commits happen

Short-Lived Branches

  • created for new features, bug fixes, refactor, experiements etc
  • they are deleted after they are merged or rebased to the long-running branches

Branching Strategies

Github Flow

This is a versy simple and lean strategy with one long running branch (main) and different feature branches


This strategy has more structure and more rules. It’s long-running branches are main, develop branches while short-lived branches are feature, release, hot-fixes and so on.

Pull Requests

The idea of pull requests is to communicate about code. It invites other collaborators in the project to provide feedback before merging is done. Pull request are also used where a contributor has no write access to the repository.

Merge Conflicts

Merge conflicts occur when integrating commits from different sources mostly when changes contradict. This means the same line changed in different commits. You can clean up the mentioned files or abort the merge/rebase. There are also automatic tools such as kaleidoscope.

Merge vs Rebase

Fast-forward merge

A fast-forward merge happens when you want to merge a branch B to a branch A and branch A has no new commits while branch B has some new commits. Both branches end up sharing the same history.

Git Fast Forward Merge

Merge commit

When both branches to be merged have new commits, a merge commit will be used during the merge. The branches will not share their history.

Git Merge Commit


This creates a straight line of commits. Example:

git rebase branch-B

The above command will remove all commits from branch A then apply those of branch B and finally appends the commits of branch A in front (made to be most recent) and hence it is a history rewrite. The commits of A will be descendants of branch B’s last commit.

Git Rebase

⚠️ This history rewrite is only safe for those branches which have not been pushed upstream.

There you have it! Thank you for reading. Feel free to leave comments or suggestions below. 🎉

comments powered by Disqus

You might also like