Experiments at work

Back with another git magic. When it comes to merging a pull request on Github, there are two options Rebase and Merge Squash and Merge What is Rebase and Merge? When one chooses Rebase and Merge, all the commits in the PR are added to the target branch. For example, if the PR has 5 commits, all of those commits will be visible in the PR history of the target branch. What is Squash and Merge? When a PR is merged by choosing Squash and Merge, all the commits in the PR are combined into one PR and then added to the target branch. Once again, if the PR has 5 commits or any number of commits, they are combined and added to the target branch. Therefore, this is what Squash means. Combining 'n' different commits into one single commit is called squashing. In this blog post, we will go through the commands that can squash commits.  Advantages of Squashing commits No more redundant commits In a pull request, one may have 'n' different commits for one change. They might have bee...

Once again, another git magic that might be of help to some of you. This research came up when I accidentally added a couple of unwanted files and wanted to remove them from a commit. We all know that to update an existing commit, we shall follow this git magic to amend commits . However, how do we drop changes to a particular file in a commit? While that is easy, it is also tricky. This blog post covers scenarios and respective commands that help you understand what should be done. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be the same as yours. */ There are two scenarios to be handled here, Remove a newly added file Remove changes to an existing file Let's look at them separately, Remove a newly added file This is the scenario where an unwanted file added to the commit. This file might be some config.json that got generated while doing a research on a new testing tool or a bundling tool. Such scenarios ar...

Back after a while with another git magic. We already have seen how to get rid of the top most commit in this article ->  Git magic - Make commits disappear First of all, it's one of the not so recommended way of doing it and more than that, it can only get rid of sequential commits from latest. I recently happened to get into a scenario where I had to drop a commit in the history by keeping the latest ones. As part of that exploration, presenting you this article. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be same as yours. */ To my greatest surprise, I didn't know a git rebase could do this. Please continue to read to know how. The steps are simple, Count until the commit line you need to drop using git log Do an interactive rebase and you're done.  Let me explain step by step. 1. Look at the commit log & count commits This is the first step. First let's list the commits using the followi...

As always, let's start with a story why I have written this one down. I have been using git for almost 5 years now and in one of my work places I had to work on the same project but different features in parallel.  Switching between branches back and forth was a costly operation given that I didn't discover commit amend until recently. Even though I'd have discovered commit amend, I'd still have did this. Still did what? I can sense that question deep from your throats. So, whenever I am in a situation to work on multiple features or a feature and a bug fix, I'd have two clones of my repo each with different branches, Whenever a feature is merged or the fixes are merged, I'll delete the clone in my machine and branch in my origin (Gitlab / Github etc.,) Recently when I started writing these git articles, my manager suggested me to learn about Git Worktree and it'll be useful. And when I got free and good understanding of git commit, rebase and stuff, I decid...

I had this interesting scenario where I did hard reset and force push to a commit. However I wanted one of the change from the lost commit.  Once again, Git magic came in handy. Git never erases anything off its memory too soon. This magic spell as I call, is one of a kind and most git enthusiasts must know it by now.  Introducing reflog We all know what you get when you do git log . Let me anyway spell it out, git log gives you a list of changes or in other words, commits available as of the moment in that local repository in the chronologically descending order.  Similarly, git reflog gives you a list if changes or in other words, change history that happened in that local repository in chronologically descending order. For instance, if you have amended the same commit 5 times, you can choose to go back to the 3rd commit amend and restart your work from there. This situation is what I call as,  Bring back from the dead Let us consider the following scenario, You w...

So, this one another thing that can mess up our repo if you don't do it the right way.  Let's go over it step by step, Pulling latest changes of upstream to your local repo Merging (or) Rebasing 1. Pulling latest changes of upstream to your local repo. So, what's the big deal? We could do git pull to get latest changes from origin to local. That's what I had been thinking until I actively started working with Github and the forked repositories. Git pull won't work here because pull could pull changes only from origin and not upstream. Now, what is origin? what is upstream? Origin - It's the repository of yours that you cloned from someone else's Upstream - It's the repository from which you created your fork Here are the steps, Set upstream URL. git remote add upstream {URL_OF_UPSTREAM} Please perform this only for the first time. After that it is set to your configuration just like username and email Now do, git fetch upstream . 2. Merging (or) Rebas...

It was my first full fledged feature and I was excited to know review comments from my manager. As much as the excitement, the learning that came with taking action on each comment was tremendous and I still can't describe how good I feel about it. It's one of the times when I thought Git to be, "Wow! what an invention!!" Although I had some code refactors, most of the comments were to split my single commit into several different commits for the sake of CI picking them up. I thought, it's simple. I can amend my previous commit to remove files from existing commit and make them part of new commits. That's where trouble came up. I cannot remove a dependency and try to use it assuming I will have that as part of an upcoming commit.  I definitely will have to go back in time to push a commit. At first I thought, I'll change my latest commit to be a dependency commit and create new commit for feature. However that involved a lot of manual work which would def...

Like I said already about hard reset , it's a nasty way to alter a commit. Then what is the better way?  That's exactly what I have written in this post about how we could use amend and what does it do. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be same as yours. */ What is amend in git commit? In git commit, when you add the attribute --amend  like git commit --amend , it lets you edit the most recent commit.  git commit --amend So, when you give this command, it opens VIM editor with your latest commit message. Here you can edit your commit message and update it & push. Is that all? The answer is no. If you have changes in any of the files and you want to add them to your most recent commit, you can stage those files to commit. Then when you execute the above command, the most recent commit message is shown in the VIM editor or whatever default editor you have along with the newly staged...

So fellas, it's been a while since I wrote and I hope this article is of help to whoever reads this.  Let's start with bit of an introduction. Until my previous employment, there wasn't much guideline on how we write Github's commit message. One single feature could have n number of commits and it doesn't bother the repository.  Now, am part of  @webex 's  webex-js-sdk  team where committing guidelines are very strict and having a bit more deep knowledge of git commands has become essential. This made me explore git commands on regular basis. So I thought why keep them to myself while I can share them. It was my first ever PR and my changes were approved except for a few minor changes. I honestly didn't know how to make changes to existing commit and now, I had two choices.  Create a new branch from master and re-do the work manually Do some git magic and make the current branch work well.  If it were old times, I'd have gone with option 1. It's very...