git – How to replace your Master

So in my project we had to face the following situation.

We have 2 main branches in our project repository , master and bug-fixing . bug-fixing was created as a temp branch so that the developers can create feature branches on-top of that. But after a while this temp branch sort of became as our main branch and when we finally decided that we need to update master branch it was too late . Because master branch was behind more than 300 + commits . So i had to find the easiest and safest way to replace old master with new updated commits . And this is how i did it.

Step 1 : Get all the updates from the bug-fixing remote branch using a pull


Step 2 : Checkout master branch and hard reset with bug-fixing branch
” git reset –hard bug-fixing”


Step 3 : Force push your local master to remote origin master.
git push origin master –force


That’s it . All under 4 commands , and your master is updated !


Yo youtube , could you please get your color combinations right !

Recently i noticed something annoying with Youtube’s settings menu . It got me so infuriating i decided to make a blogpost about it .



The color combination they’ve used for the toggle switch for Autoplay , Annotations are virtually unidentifiable . Both switch on,off states have been differentiated using a grayish color combination . So for example, you have to really look twice to know whether the  Autoplay is switched on or off.

After adding some contrast to “on” state in toggle button – making it intuitive.


See now it looks slightly better . A basic rule in UX is that when you want to differentiate two states in UI , you go for complementary color rule . So even a 70 year old grandma who wants to play her favorite cat videos on Youtube knows she has the set Autoplay option correctly by just looking at the color of the toggle switch .


bonus link : Adobe color wheel . Very useful when you want to select color combinations for your UI.

Vue is not detected : How to fix vue dev-tools issue

Vue dev-tools is a handy little tool developed by VueJs to make the debugging easier when you develop Vue Applications . Currently there is a chrome extension available . Also you can install it via yarn or npm as well .

But sometimes you might come across a issue like this when you try to use this tool .

Vue is not detected.PNG

Following are few ways to fix the issue .

  1.  First of all , make sure you are using a non-minified version of VueJS.
  2. If you are using File:// protocol , By enabling “allow access to file URL’s option” in the chrome extension

    after this try closing and reopening the chrome .

  3.  By adding the devtools = true in the app.js file .
    Vue.config.devtools = true

    More info here
  4. If non of the above doesn’t work , try loading your Vue app over a local http-server.
    Here is a simple http-server. And close and reopen your chrome tab .

I was able to resolve this issue by following option 2 and 3 .

Vue is not detected solved.PNG

When to use git rebasing and why ?

note : My earlier post was about some of the useful commands of git and how to use them

Git rebase : introduction

Git rebase is a handy mechanism when you need merge the changes of your branch with another branch (probably with the master branch) . But the process behind a git-rebase is not that simple as the definition suggests , but it is clean and awesome . In this post , I am going to go through with the process behind a git rebase , when to use it , and when to avoid it .

Let’s look at the following simple scenario..

Say you have a master branch called master .. (duh)

And you are creating a development-branch out of this master branch to do your development stuff.


And you are now working on this development-branch for sometime . You make changes , you add these changes and you commit those changes to this branch . Now after few days , you decides that it is the right time to integrate your changes to the master branch . But guess what , your team members have already pushed their changes to the master branch . So you cannot just easily merge your changes to the master without messing up the changes of your peers . Following diagram illustrates the situation


As you can see there is a gap between the branch you are working on and the master . This is where the it rebase comes in .By using git rebase you are going to integrate your changes (commit B1 , B2) with the master (Where now the head is located at commit M3) ,


Now the situation changes to something like below


When you use git rebase , the commit history (commit hashes) changes entirely . That is why i have used the green color to represent the history instead of blue (color of master’s commits) or red (color of development-branch commits).

The Advantage

It creates a linear History which is the very reason why we need to use git rebasing. Your history is clean flat and readable . You can identify the commits of each of your team members very easily in different timelines .

The Disadvantage

In a situation where you have so many people consistently pushing their changes to master and when there are so many branches being merged with the master , It is kind of a pain in the a** to keep your branch upto date with master using git rebase . You have to constantly do the rebasing , and might need to resolve conflicts time to time

Also rewriting your commit history after each and every reabsing is not always a good thing . It means that your commit hashes change consistently and also , you need to force push every time to the remote after a rebase

When to use git rebase : Only when you need a clean linear history so that you can clearly see what is going on with the all the commits from all the team members

When not to use : If you prefer to follow a simple mechanism where you can integrate your changes with the upstream branch without a fuss you can always go with git merge

How to face software engineering internship interviews ?

I got the opportunity to do few interviews and mock interviews for the interns who were trying to get into the Industry as trainees . What i have noticed from the candidates are that they are extremely skillful , had good academic track records and some of them are very good at problem solving . However what i didn’t see was the preparation to face an interview . When the most common questions were asked , i saw the lack of ability to tackle those questions mainly due to the absence of preparation . So i thought of writing few tips on how to tackle an internship interview.


How to face it better ?

First things first : You should prepare a small “about-yourself ” description to introduce yourself to the interviewer . Because the first question would almost always be something like “Can you first tell us about yourself a bit” . This is something everyone easily messes-up  because it is so obvious !

Stick to the script : When you introduce yourself to the interviewers , make sure to keep it short and sweet . It should be relevant to the internship . For example after stating the basic information (name , age , where you live ) , go with your overall academic records , projects you have done , any important contributions you have done to the IT community (such as open-source contributions , tech publications) , any interesting hobbies and a bit about why you selected this field . You might not want to share your pet’s name , what your parents doing for a living .

Bring a copied CV : This is important and is something always expected from a interviewee .

Loud and clear : Some people are naturally soft spoken . But when it comes to interviews you need to make sure what you are saying is delivered to the interviewer . If the interviewer had to ask you again and again for something , it will create a negative impression . It will also show you that you are not in cable of having a efficient communication .

Confidence and eye-contact : Don’t bore your interviewer by acting slow and dull . Show your enthusiasm in your voice and always keep a good eye contact .

Be honest : When you are asked about something about your self , make  sure you give the correct details . If you are not being honest at that time and if the interviewer later found out that you gave out incorrect details , you are done .

About your projects : Always have a look at the overall information about your university projects and you need to prepare for this before coming to the interview . There will be a question like “Tell us about your university projects” , So in that case it is important that you know how to explain what you have done . You might have done several projects , in that case , select one . 3 things need to be said during this question.
1. Project description (domain , techs used , overall system architecture)
2. What is your contribution
3. Problems faced and the assumptions made

Think out loud : You will be given some kind of problem/scenario where you are required to provide a solution . The solution might be some pseudocode/algorithm or some high-level system design . Sometimes what happens is that you think about a solution in your head without expressing it ,Which will result in a uncomfortable silence between you and the interviewer . In this case a pen and paper might come in handy . You can sketch it and show as to how you will approach the issue . So the interviewer will know you got the idea.

Keeping your self updated : When it comes to IT field , It is imperative that you know a bit about the latest techs and trends . So always keep your knowledge polished by readings blogs , magazines etc. Also having a basic knowledge about the company is a must . Go through the company’s website , Facebook page , LinkedIn or another SM accounts and get an overall idea as a part of the preparation for the interview .

Social media profile : Having a LinkedIn profile is a good way of marketing your self for a job . Remember to include this in your CV . Also if you managed a blog , if you have a stackoverflow or a github account , share it with your interviewer . This will help him to understand your skills better.

Passion and Mission : Another obvious question is “How do you see yourself in n number of years” . Always prepare for this question before the interview . Also your plans should be relevant to the internship and the field . “I want to buy a car and go around the world” is wrong kind of answer !

Ask questions : Interviewer :” Do you have any questions to be asked from us ? ” . Keep at least two questions prepared to ask at this point which also needs to be relevant to the context .
For Example :

  •          What are the new projects are being developed by your company ?
  •          How this place will help me to improve my career path ?
  •          If i get selected , what projects would be assigned to me ? what kind of part would i play in the company/project ?

Few things you shouldn’t do ..

Asking personal questions : Interviews are for professionals so act like one.
Lying about the qualifications : If you have a 3.45 gpa, then it is what it is . Do not round it to 3.50. Always be honest.
Do not “build” answers : If you were asked about a technical question and if you don’t know anything about it , do not try to build a fake answer just for the sake of it . Remember your interviewer knows his stuff . Lying about something you don’t know is a waste of time and you will lose your integrity at the very moment .

Don’t ask about the salary : In your first interview for internship , asking about the salary is probably not a good idea .

Git : How to merge your silly little commits into one .

There are three kinds of git users . People who commits every single change ; People who wait and compile all the changes into one gigantic commit . And the last kind is the best kind , who commits in a responsible way. I used to be the first kind , but realized later it is annoying to the people who reviews my PR’s . So i did some digging and as always git has the answer to almost all of your problems (May be not how to deal with a breakup with your girlfriend . In that case Git cannot help ya 😦 ) . So here is the thing , git has 2 helpful ways of dealing with this problem .

  1. Using squash mechanism
  2. Using good old git reset

Here is the scenario . Say if you made some commits with small changes like remove small space 1 , change variable name , remove space 2 . Later you realize the commits are kind of silly , you want all these commits to be merge into one called something like code cleanup .

Using squash for this problem a bit complex (not if you get used to it) . But it sort of gives you an overall idea on what is happening . This is how you do it .

Method 1 : Using squash mechanism

First of all make sure your master branch is up-to date with the related upstream branch . And say you are in a feature branch called , well feature-branch .

in your git bash , run this command git rebase -i master


you will get the vim interactive console and you will see all of your 3 commits listed


Here the process is simple . You can pick one commit which can be your parent commit  using pick, and the rest of the commits can be linked under this parent commit using squash command . Also you can change the order of the commits as well . So according to our scenario , we can do something like this …


So yeah that is it . Just save and exit . And you will get another interactive console like below ..


You can just skip this window by just quitting without save or you can give new names to your commits . So here i am renaming the top most commit (which is my parent commit of all 3 commits) as Code cleanup . And again save and exit .. You will see something like below ..


That’s it , you have successfully merge 3 of your silly commits into one commit which is going to make a better commit history for you . Now you can just use git push origin feature-branch –force to push your single commit to the remote repository .

Note : we are using –force because this process has changed the commit hashes . In any case , when you use force push , you need to absolutely make sure you know what you are doing .

If you go to your repository and view the commit history , you can see the squashed commits like this visualized in a different way ..


So that’s how you squash your commits in Git . It is a bit time consuming process , but if you get used to it , it is very useful .

Method 2 : Using good old git reset

So unlike squashing your commits , you can easily merge your little commits into one using git reset command . It is really simple . Take the same scenario i have mentioned above . Now what you need is , Taking the HEAD position 3 commits back . By doing this you are resetting the last 3 commits .

git reset –soft HEAD~3

Now you have un-stage changes . All you need to do now is to put them into a single commit

git commit -m “Code cleanup”

Or better way , merge these 2 commands into one

git reset –soft HEAD~3 && git commit -m “Code cleanup”

There you go  ! That’s it . now push –force to push the new commit into the remote repository . The same warning regarding force push applies here as well .

The awesome thing about these 2 methods is that you can change the commits even after you have pushed the changes into the remote repository . So don’t worry , it is never too late with git .

more info on squashing can be found here