Git Best Practices Simplified

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

GitFlow

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

Rebase

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