Git quick reference

This is a quick reference on how to use git; notice that the shortcut work because of the webo-dotfiles

Clone

Cloning is the operation of retrieving a complete copy of a repository online. Every time you navigate to a project in gitlab, you have access to the repo url (for the webo-dotfiles, for example, the git repo url is [email protected]:weborama-nl/webo-dotfiles.git)

git clone <repo url>

Creating a new git project

If you want to create a project that will be available online, the fastest procedure is click on the new project button (a plus in the right part of the top nav bar) in gitlab, and then clone that project in your own workspace.

If you just want a local repository, you can use init:

Init

To initialize a git repository, just create the directory , navigate into it and issue a git init: this will create a private repo:

mkdir myProject
cd myProject
git init

Status

retrieves the status of the repository

git status (or g st)

Diff

see the differences that you introduced

git diff (g diff)

How to commit

To commit, you have to select which files you should commit. You can add single files:

git add src/filename.js

Or alternatively, add all the files:

git add --all

Then you can commit

git commit

or, more shortly:

git ci

This will open up vim, a command line editor where you can edit your commit message (which is mandatory). Vim is really old style, so here are the commands you will need:

i to insert,
esc to exit insert mode
:wq to save (w) and quit(q). Oh, press enter after this

Push your changes online

Commits are local; your local repository contains already all the history of the project. Git can work even without a remote server, and that's quite handy. However this also means you have to explicitally push your changes to the remote server when needed. To do so, use git push:

git push

Retrieve online changes

Same stuff if you want to get updates from the online sources; you will need to explicitally get them. You can use

git pull

or the shortcut

g p

Browsing the history

Looking at the history of files is quite powerful; you can use these commands To see the full log

git log

(you can use git log --name-status to also see the names and statuses of the affected files)

To see a short version of the log, you can use

g l

Git best practises

Atomic commits

A commit should contain one and only one irreducible unit of change

A commit should contain changes that are related to one single irreducible task. Do not fix a bug while adding a feature. Do not change your build system (.jshintrc, gulpfile, etc.) while doing something else.

Every commit is a single unit of work: you should be able to remove a feature that you added by removing the single commit - without affecting anything else.

http://seesparkbox.com/foundry/atomic_commits_with_git

This brings us to the usefulness of Semantic commit

Semantic commit messages

Commit messages should always use the same format and provide structured information

Using a rigid commit message format helps in keeping your commit atomics.

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense, imperative form
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

http://seesparkbox.com/foundry/semantic_commit_messages

DavideMontersino/git_quick_reference.md