Git - magical version control

I know this is a very late post as compared to the time Git has been rocking the world of distributed code management, but I was introduced to it 18 months ago and I am still too ecstatic to just let this post go. So, for those who are unaware of git (though I highly doubt it), it's a way to do version control for code which you know is going to be messed up one way or another by your teammates before it's pearly white and ready to deploy. So, to avoid tiny heart attacks, every time you get back to your code and see a minute change giving null pointer exception, git is the solution. The people behind designing this masterpiece have taken into account every scenario and have devised simple and efficient ways to handle them. Some of its 'magical' features that make my life easy breezy are branching, pull, safe boundary between commit and push and so on so forth. Branching will let you create your own working space branched from the current version of the base code. You may start with cloning (or copying) the base code to your local drive and creating a branch after that. When you switch to this branch and make your changes, those are reflected in your section only and can be worked on in your local drive. When you switch to another branch, the same location in your drive gets altered. No other folder or copy is created to increase confusion, but the same root gets altered. Don't panic! It will just reflect the stuff from the branch you are in. This property amazed me the first time and I still find it quite smart. Next would be 'pull'. If you want to update your branch or create a new one with changes from another branch, you can do so with just one command..pull. It is easy as the name. It will merge the remote master branch into the current master branch leaving your changes alone, so basically an incremental update. Another feature I like is that the commit states are saved. You can always rollback or simply check the status of the branch at a certain point of time. It allows you rollback for all the past commits, not only a few recent ones. Now, separation between commit and push. Say you want to make sure that your current progress is saved but you don't really want to change all the files because you are not quite sure. Well, you can commit your code. It will save the state of your code at that instant without making explicit changes to your codebase. When you really want to update, 'push' your code and you have it in your branch. Merge is another great and maybe the last thing to do in git. This will combine your solo branch to the mother ship (or any other branch). This should be done at the final stage as you are submitting your finished code to its origin. And git has so many flavors, the commands and rules are same everywhere and you can prefer whichever you like. There's github, gitlab, bitbucket and maybe more. There are some thumb rules that you can follow if you are new to git and rest you can learn along the way.

They are*:
1. Always leave a commit message. Make it precise, preferably short but not vague. And do not repeat them; it's confusing and makes no point.
2. Clone:

git clone [--template=<template_directory>]
 [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
 [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
 [--dissociate] [--separate-git-dir <git dir>]
 [--depth <depth>] [--[no-]single-branch]
 [--recursive | --recurse-submodules] [--] <repository>
 [<directory>]

3. Branch:

git branch [--color[=<when>] | --no-color] [-r | -a]
 [--list] [-v [--abbrev=<length> | --no-abbrev]]
 [--column[=<options>] | --no-column]
 [(--merged | --no-merged | --contains) [<commit>]] [<pattern>…​]
git branch [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
git branch --unset-upstream [<branchname>]
git branch (-m | -M) [<oldbranch>] <newbranch>
git branch (-d | -D) [-r] <branchname>…​
git branch --edit-description [<branchname>]

4. Commit

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
    [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
    [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
    [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
    [--date=<date>] [--cleanup=<mode>] [--[no-]status]
    [-i | -o] [-S[<keyid>]] [--] [<file>…​]

5. Check status

git status [<options>…​] [--] [<pathspec>…​]

6. Push

git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
    [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose]
    [-u | --set-upstream]
    [--[no-]signed|--sign=(true|false|if-asked)]
    [--force-with-lease[=<refname>[:<expect>]]]
    [--no-verify] [<repository> [<refspec>…​]]

7. Merge

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
 [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
 [--[no-]rerere-autoupdate] [-m <msg>] [<commit>…​]
git merge <msg> HEAD <commit>…​
git merge --abort

8. Pull

git pull [options] [<repository> [<refspec>…​]] 

9. Tools to make life easier - if using command prompt is not your thing, then there are tools and extensions available to allow fetch, pull, commit etc. only a click away. You can use git gui, git extensions and many more tools to visualize what you're doing.

It could get a little confusing seeing all the splendid things git can do, but the documentation from these guys is extremely easy and quick to grasp. Also, when you are writing a tutorial or blog about a project, you don't have to store your code on some third party cloud service, instead you can give the git link to it. Git kinda acts as a CV of your projects. I would much rather prefer giving the git link instead of writing about my project without a proof. And if someone checks out my git repository, that's even better as I don't need to list my code-based projects on paper any more! So, hack your heart out and leave the rest to git.

*www.git-scm.com