Squashing Commits With Vim (On VsCode)

When you about to do your first PR (pull request) it is important to know how to squash commits correctly.

Why? you may ask
- Well i know that you are probably good programmer and organized person, and you always use to give a second look before pushing something - to make sure the things are intact, but, somehow, sometimes, after pushing the commit (you checked before all and over!) - you find yourself looking at embarrassing typo you mysteriously missed while checking.

 So, what to do now? One way is to start all the thing again from the beginning (new branch, merge changes, new PR etc... ), but is it the only way?

 Fortunately (unlike real life) - there is a way to rewrite history - the rebase command!

 So, in case you found a typo - all you have to do is:
1. commit again (git commit -am "fixing typo")
2. run

git rebase -i HEAD~2

(because you want to squash 2 commits)
3. after running this command you will present with following screen: (in windows you need to press 'i' for enter into 'insert' mode)

4. modify the row of latest commit and replace 'pick' with 's'(squash)

5. (windows) press ESC(for exiting 'insert' mode)
6. (windows) type :wq to save changes and quit
8. in linux you just press CTRL + X



After selecting which commit to squash, you will present with screen where you can reformat the message of single commit you about to generate. You can just leave the message of original one and comment the others with '#'

7. run 

git push -f origin your-pr-branch-name

Now, look at your remote repo "commits" log: no traces of embarrassing typo, just one clean commit!

Imagine you could replay this way the world history and, for example, prevent the WW2... could be great, right?


Thats it,
Hope i helped someone in my situation

See you in my next post!

Doing git commit --amend (first time)

Every git user get through this experience: You did commit and immediately after you realized that you forgot something embarrassing...
Thats exactly situation --amend option is built for. It is for getting new commit to be merged into previous one so in git history you will see only one entry (the last one)...

For example:

Lets say you notice that you have some extra file inside your project, that shouldn't be there, you can remove it and commit with following command:

git commit -m "removing extra files"

Lets see that commit registered in git history:

Now lets say, after have second look on your project you notice one more extra file and you need to commit again:
This time you can use amend

git commit -m "remove extra zip file" --amend

Now you can see that in history remain only one entry with latest commit message.

What Is Rebase Command Of Git For?

It is long time i working with git and i must admit i didnt figured out the meaning of Rebase command. Fortunately i hope i figured it now. It appears now that key point here is the git history.
It is important to keep each of commits to be as clear as possible - what is this commit about.

Sample

Let start with example repo where we have two issues open:
1. upgrade protractor library (technically to change version num in "package.json" file)
2. move some file from ES5 to the typescript
The common flow is that each bug/feature developed in its own branch and merged to the main "master" branch afterwards. Lets say the issues where split between two team members - mr X:

and mrs Y.

Mr X created branch named upgrade-protractor wile miss Y created view2-to-typescript at the same time.
Since mr X's task was much easier - he finished before miss Y, and committed his work. According the flow, mr X should do pool request, after that his changes where merged into master.
Now , after miss Y will finish her work and commit - she will face problem to merge her changes into master since it had changed meanwhile.

Good Old Merge

The simple way to handle the problem is to do

git merge master

which will create special "merged" commit because of merge action:
Now the view2-to-typescript has the protractor version change inside it and can be merged into master.
The disadvantage of this way is that commits log has a commit with changes which have nothing to do with the typescript task

Thats Where Rebase Came To Play

The nicer way to handle the merger-to-master problem is to do:

git rebase master

That way the history will be "rewritten" and only one commit with the relevant changes will appear in the commit log: