Commit Related Tips

• A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits.
• Avoid mixing whitespace changes with functional code changes.
• Avoid mixing two unrelated functional changes.
• Avoid sending large new features in a single giant commit.
• Resist the temptation to commit something that you «think» is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing/sharing your code with others.
• Commit code when it‘s completed. Don‘t Commit Half-Done Work
• Small, logical commits.

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

• Split the feature‘s implementation into logical chunks and remember to commit early and often. But don‘t commit just to have something in the repository before leaving the office at the end of the day. If you‘re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git‘s «Stash» feature instead.
• Always review code before committing it
• Never rebase shared commits Branches
• Keep Branches as required
• Begin your message with a short summary of your changes (up to 50 characters as a guideline).
• Separate it from the following body by including a blank line.
• The body of your message should provide detailed answers to the following questions:– What was the motivation for the change?– How does it differ from the previous implementation? Use the imperative, present tense («change», not «changed» or changes») to be consistent with generated messages from commands like git merge.
• Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Write “fix”, “add”, “change” instead of “fixed”, “added”, “changed”.
• Always leave the second line blank on Git Commit Message

Branching

Commit Messages

Sample Message

Summarize clearly in one line what the commit is aboutDescribe the problem the commit solves or the use case for a new feature. Justify why you chose the particular solution.

Help & Documentation

Get help on the command line

$ git help <command>