Git in 10 minutes

Hi Guys. I am writing this article after really a long time.

So this article is for all those people who knows what the git is but do not how to use it appropriately. Now don’t be ashamed of not knowing, I was in a same condition one year back and today, I can proudly say that yes, I know how to use git properly.

Let me share the funny part first. When I first went through git is I never used it to its fullest. I would push my code to github so that I contribute to the open source and people can see my code. I would push my code to github or bitbucket, so that in case my system blows off, there is some code accessible online. Frankly speaking remembering those commands were headache for me initially(but if u understand properly nothing is difficult). Most of the time I used github just to showcase my work. Such a dumb person I was still I am but little less :D.

I don’t want to go all into git and what github is. I will write article regarding what git and lot many things next time. But this article is for the people like me who know what the git is but never used the way it has to be.

So lets first know what the git branch is . When you create your repository for the first time, your repository will have an initial branch called as master branch. According to the convention master branch should be updated only at the point of deploy or when we are sure that your change is final and your done, normally we follow this routine at our work place. So master branch is untouched till we are reached at the point of deployment. Just 1 minute before the deploy we merge required branch in the master and we deploy.

If there are many collaborators for a repo try to create a new branch from the master or the staging branch(let me come to the staging branch later and concentrate on the branch first).

Branching is damn easy in git. to know your current branch type git branch

$ git branch
adding_angular
adding_capistrano
code_refactor
adding_google_authntication
*master
adding_state_machine

In order to create new branch you will have to type

$ git checkout -b new_branch
Switched to a new branch 'new_branch'

this will create a new branch on your system, as soon as you create a new branch you will be checked out to the the new branch. Keep in mind that new branch created will exactly be the copy of the branch previously you were on. So whenever creating a new branch its better to create a branch from master or from the staging branch. If you feel like switching the branch you can use git checkout command.

$ git checkout master
Switched to branch 'master'

Now when exactly to create a new branch? Supposing say you are working on the new feature in a project, for example adding state machine to your rails project, or say adding authentication and authorization to your project then instead of clobbering master or any other branch create a new branch. Once you have created your new branch your are ready to do any changes on it and commit it(check my list above in case you don’t know).

Wait wait if you are not aware commit also has its own way. You do not commit anytime and every time. There are certain rules which you need to follow while committing. Commit always needs to be a sensible commit, example if you have added an model level api to the code then commit it with appropriate message I am again saying with appropriate message. If you are not aware you are allowed to write paragraphs also in commit messages.

 — gem updated
— route added to change settings
— model level function added to change settings
— caching keys changed
— user model function added to assign
— date mixin updated
— keys changed to handle settings
— on change event handled
— comments handled appropriately

Above is how my one commit message sometimes looks like. It should perfectly describe what code changes are done. BTW I am very bad at writing messages, although I am improving at it( I always get shouting for not naming functions properly or not having proper commit messages). So your commit should appropriately describe what did you add in the code. In case there is some major f*** up because of the code you wrote, then other person can know from the commit what did you do, otherwise its extremely difficult to know whats going on inside the coders mind when he was coding. Most of the times I don’t remember what I wrote 1 month back, only from the commit I can recollect why particular code was written. So your next commit will be controller level changes done.

 — commit messge will be blah blah blah

next commit may be say,

 — ui level chnages done

and now congo you are done with the authentication and authorization. Now if you are damn sure with your code then you can directly merge your branch into the master or the staging branch or you can raise a PR(coming later to this point of staging branch).

Okey what is PR? Now don’t tell me you do not know what is PR. And if you don’t know please don’t google it. I also had no idea for the first time, when some one told me to raise a PR(first time dude chalta hai). PR is a pull request. If you are using git hub or bit bucket, once you push changes to your branch it will allow you to create a PR. Pull request will allow you to compare code between 2 branches. Why is it useful? dude then you just don’t have idea about code reviews. while reviewing a code its extremely important to have a PR. It will let you know what all code changes you have done. It will also let you know if there are any harmful changes you have done to the system. Basically its a relief for your boss or team leader and night mare for you to get reviewed :P. Once you raise a PR everything is under you bosses nose and he can check each and every line of your code, and probably blast you with the comments, in case you have done silly mistakes or changes which will make entire system go dumb . Be ready to get comments like `WTF this line is removed for` also. Once you get thumbs up for the PR you can basically merge the PR into the branch against which it was raised.

So lets come to the staging branch(most awaited). Supposing say 2–3 people are working on one feature in a project lets give that feature a name as of revamping authentication and authorization (This will involve crazy shit of adding permissions to new user and changing permissions of the old users, ui to accommodate this changes, and lot of model and controller level api changes).

Lets take a new feature and divide the work into small things like one person is handling ui, second person is handling the model level api and permissions part and third person is handling the controller api. Now if you try to make one branch and all 3 people start working on the same branch it will be a crazy mess. There will be so much of code removal and code insertion, that at the end you will go crazy handling the code conflicts. (code conflict is a thing where git also does not understand how to handle your code, so you have to handle it manually this will kick your ass I swear).
SO best part in this situation is to have one intermediate branch say revamping_authntication_and_authorization.

Now first person working on the ui part will create new branch from this branch lets give that branch name as revamping_authntication_and_authorization_ui.

person working on model level api and permissions will create new branch with name revamping_authntication_and_authorization_adding_model_and_permissions

person working on the controller level api will create one more branch say 
revamping_authntication_and_authorization_adding_controller_api

So now we have 3 separate branches created from a parent branch revamping_authntication_and_authorization. Every individual can do whatever he wants to on their personal branch and stay in peace, why? because there is no blame game here, you don’t have to type that extra comment of git blame and see who added the code in the file you are working on . SO best part will be you are your own boss in your compartment.

SO Now once every individual finish their task they can raise a PR against revamping_authntication_and_authorization please read it again raise PR against revamping_authntication_and_authorization and not master, because as I said earlier master is not a branch to be fooled around, it has some dignity and that is why its called as master so never ever pollute that branch. Raise a PR against your staging branch do a PR review merge the PR and test your staging branch at its best, on a test or the staging environment. Once you are confident enough merge into the master and bang you are done with your task.

So this solves the mystery of staging branch I guess.

There are lot of beautiful concepts in git which I am just in love with. 
like following one

$ git cherry-pick commit_hash

This will properly explain you why there needs to be a proper commit and why was I stressing it continuously on commit. As you know every commit has a hash associated with it. If you do git log you will get to see all the commits messages and hashes for your project.Supposing say by mistake you did one commit on a branch which you were not suppose to, now will you sit copy pasting that code from one branch to another? then please dont for god sake, best way would be to cherry-pick that commit from the other branch into your branch. you will have ditto same commit hash, message and code transferred to your branch with just one magic command. I am seriously in love with this command and Linus Torvalds too.

$ git cherry-pick b8b1286

In case you did some rubbish changes on your branch and your boss ordered you to push the code write now. Now what? dont think you are f***** do git reset — hard. This particular command saved my ass lot of times.

$ git reset --hard commit_hash

Mind you that this command is safe in case the commit from which you are resetting to is not pushed to the remote. In case you have already pushed changes to the remote, you will not be allowed to push the code. Now what? do namo, namo? No dude you are suppose to do git git 
so next command would be to push your code forcefully. This will push your code forcefully with the head you have reset to.

$ git push -f remote branch_name 

This will reset your remote with the local head pushed. But mind you that once you do hard reset there is no way to get earlier code back(I did not find any way, if anyone does please comment it with the solution below).

Another command which I just love is git stash. God always creates some secret place either for you or for your code, so git stash is similarly a secret place. Supposing say you do not want to commit your changes, or you are in middle of something, you are not sure if its in a commit able state but you want to checkout to other branch without committing your code, git will not allow you to checkout, so best part would be like to stash the changes.

git will only prompt you saying stash your changes before checkout otherwise it will be lost and now its your responsibility to search more about what this stashing is. If you do git stash list

$ git stash list
stash@{0}: on git_article: changes left to be pushed
stash@{1}: On personal_artcile_bora_bora: email changes on the way
stash@{2}: On locking_syetm_article: locking
stash@{3}: On testing_article: screen shots are left

It will show you all the stashed changes in your system, basically git maintains a stash stack where in all your unsaved changes will be pushed to it when you do git stash.

$ git stash

will just push you unsaved changes to the stash

$ git stash pop 

will pop the topmost unsaved changes from the stash.

Now what in case you want to pop the changes which is at stash number 4. don’t even think of popping all stashes one by one, and I don’t think git will allow you to do that, because you need to commit again or stash before popping another stash. so there are commands in git to directly pop the required stash.

$ git stash pop stash@{stash_no}

If you want to keep the stash in the stack for further use and want to use it later in another branch suppose, then best thing would be to use git stash apply.

$ git stash apply stash@{stash_no} 

and boom you are done. There is one nice way to save your stash also. Normally when you stash your changes using git stash, it will show the current branch name and previous commit name on stash list. Most of the time you will wonder why did I save this? or for what did I stash this changes on this branch for? and this literally keeps you in wonder land wondering around. So best thing is to give your stash some honky ponky name, example.

$ git stash save ‘bored with coding so going for tea’

now wen you do stash list, instantly you will know why did you stash something.

This is just a basic of git for the ones who were not using git properly till now. There are many more things to come on this particular topic.

I liked linux from the day I started using it but fell in love after the way I used git.

Seriously love Linus Torvalds for creating such an awesome feature. I appreciate you for reducing my pain in handling this code.

Stash is only for little amount of code and is not the place to keep your code permanently, so you need to empty unnecessary code when bored . Normally I clear my stash every week. As I said this is just a temporary place to hide your code.

Git entirely is a waste topic but as said by someone nothing is impossible in this world. You can literally go deep inside once you are string with it. There are various tools for linux as well as windows which I would like to discuss in the next article.

Entire article written is based on my experience on using git, so far there are no references included except for some git command.

#happycoding

Like what you read? Give Ankita Palekar a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.