Git Cheat Sheet (Page 2 of 2) in pdf

fournova

version control

besT pracTices

Commit related Changes

test Code Before yoU Commit

Use BranChes

A commit should be a wrapper for related

Resist the temptation to commit some-

Branching is one of Git‘s most powerful

changes. For example, fixing two diffe-

thing that you «think» is completed. Test

features - and this is not by accident:

rent bugs should produce two separate

it thoroughly to make sure it really is

quick and easy branching was a central

commits. Small commits make it easier

completed and has no side effects (as far

requirement from day one. Branches are

for other developers to understand the

as one can tell). While committing half-

the perfect tool to help you avoid mixing

changes and roll them back if something

baked things in your local repository only

up different lines of development. You

went wrong.

requires you to forgive yourself, having

should use branches extensively in your

With tools like the staging area and the

your code tested is even more important

development workflows: for new fea-

ability to stage only parts of a file, Git

when it comes to pushing/sharing your

tures, bug fixes, ideas…

makes it easy to create very granular

code with others.

commits.

Commit often

Write good Commit messages

agree on a WorkfloW

Committing often keeps your commits

Begin your message with a short sum-

Git lets you pick from a lot of different

small and, again, helps you commit only

mary of your changes (up to 50 charac-

workflows: long-running branches, topic

related changes. Moreover, it allows you

ters as a guideline). Separate it from

branches, merge or rebase, git-flow…

to share your code more frequently with

the following body by including a blank

Which one you choose depends on a

others. That way it‘s easier for everyone

line. The body of your message should

couple of factors: your project, your

to integrate changes regularly and avoid

provide detailed answers to the following

overall development and deployment

having merge conflicts. Having few large

questions:

workflows and (maybe most important-

commits and sharing them rarely, in con-

ly) on your and your teammates‘ personal

– What was the motivation for the change?

trast, makes it hard to solve conflicts.

preferences. However you choose to

– How does it differ from the previous

work, just make sure to agree on a com-

implementation?

mon workflow that everyone follows.

Use the imperative, present tense

(«change», not «changed» or «changes»)

don‘t Commit half-done Work

to be consistent with generated messa-

ges from commands like git merge.

You should only commit code when

help & doCUmentation

it‘s completed. This doesn‘t mean you

Get help on the command line

have to complete a whole, large feature

$ git help <command>

before committing. Quite the contrary:

Version Control is not

split the feature‘s implementation into

a BaCkUp system

logical chunks and remember to commit

early and often. But don‘t commit just to

Having your files backed up on a remote

offiCial git WeBsite

have something in the repository before

server is a nice side effect of having a

leaving the office at the end of the day. If

version control system. But you should

you‘re tempted to commit just because

free online resoUrCes

not use your VCS like it was a backup

you need a clean working copy (to check

system. When doing version control, you

out a branch, pull in changes, etc.) consi-

should pay attention to committing se-

der using Git‘s «Stash» feature instead.

mantically (see «related changes») - you

shouldn‘t just cram in files.

30-day free trial available at

the most powerful Git client for Mac

Git Cheat Sheet Page 2

Related Articles

Related forms

Related Categories