Introduction

Oftentimes, if not always, there will be situations where you will wish to, or more frankly, need to skip doing a commit due to some reason, the most frequent of which is due to some sort of conflict, as most people suggest.

Table of Contents

For such scenarios, the –skip flag is just the thing you might be looking for! Let’s say you’re trying to merge a commit from a different branch to your main branch using the rebase command, but parts of the content are conflicting. You have two choices for this. You can either fix the conflicts manually, and live life in peace. However, if the conflict is visibly large, it might be harsh enough to ruin your sleep.

To add up to your existing pain, it doesn’t end there. Because you’re left with a conflicted commit, which is sure to cause you more trouble at a later time. This is when your only solution is the second option, which appears to be the ‘git rebase –skip’ command.

git rebase example scenario

Let us produce an example scenario to better demonstrate why you may choose to use the –skip flag with git rebase. Starting off with the initials, I’ll first create a folder, initialize it, and then add a new file.

$ git init
$ git touch index.html
$ git add index.html
$ git commit -m “Added a new file”

Now let’s add some text to the newly created file and commit it:

$ echo ‘Hello, World!’ > index.html
$ git add index.html
$ git commit -m “A new line is added to index.html”

So far so good. We created a file and have added a line of text to it. Now let’s say I want to add some more features to the file, but don’t really want to mess with the original one. What’s the way? yes you got it right! I’ll be creating a new branch, using the checkout command in git:

$ git checkout -b feature

Alright. I’ve now switched to the new feature branch, so I’ll add the extra line which I’d like to merge with the master branch’s index.html file:

$ echo -e ‘This is the new line I wanted to add’ > index.html
$ git add index.html
$ git commit -m ‘The extra line has been added’

Oh wait! I forgot that I had to add another line of text to the index.html file in the master branch, let me do that just now!

$ git checkout master
$ echo “I needed to add this line before merging” >> index.html
$ git add index.html
$ git commit -m “Another new line added”

Huff! It’s about time I merged the new content from the feature branch to the master branch. I have two options for this, git merge and git rebase. Both of them pretty much carry out the same job, but how they do so and what they leave behind has a few differences, which I think is not ideal to get into right now, as our main objective is to demonstrate the use of the –skip flag in git rebase. So probably, I’d use the git rebase command:

$ git rebase feature

Alas! We had a merge conflict!

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
error: could not apply 17028d2... New content
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 17028d2... New content

As you should already be able to see, there are a few hint texts which try to give you a few fixes that you could try. Most visibly, we have mainly two fixes that we can apply – either fix the conflicts manually and continue the rebase process, or totally skip the commit.

Try to fix it manually

This one is quite obvious and straight-forward. You need to either make changes to the file from the branch you’re trying to merge, and then continue the rebase process. In our scenario, this shouldn’t be too much of a hassle as we only had 1 line that’s conflicting. So I could noy simply revisit by feature branch and then either remove the new line, or change its position to avoid any further conflicts. Once I’m done with it, I can switch back to the master branch, and finally apply:

$ git rebase --continue

This will resume the rebase process from where we left off last time. Given that I properly fixed the conflicted parts, I should see no further errors now.

That does not sound too shabby, does it? But what if our file contained a whole lot more conflicts, that could go out of order, and right now I’m not in the situation where I can go and fix every single conflict? This is exactly the right place to use the –skip flag.

Use ‘git rebase –skip’ to skip the commit

To ensure that I’m not left any conflicts with my existing files, I’d simply use the following line of command from my master branch:

$ git rebase --skip

This will ensure that no changes are applied to the files in the master branch, and everything will stay as is. What you should not hear, is that not only the conflicting parts will be skipped, but the changes overall. So if you expect it to apply to other sections except for the conflicting ones, it wouldn’t happen.

‘git rebase –skip’ vs ‘git rebase –abort’

Both of these commands will prevent any changes from being made, however, there’s a slight difference. After you successfully apply a git rebase command, what you should notice from the output of git log is that the HASH changes. This is because rebasing changes the previous commits entirely, and creates new ones, even if you choose to use the –skip flag. In such scenarios, if you don’t want your previous commits to be replaced with totally new ones from the rebasing, you’d rather want to use the –abort flag with git rebase.

This will not change anything at all, and will revert back everything to as it was, pretending like nothing had happened!

When to use ‘git rebase –skip’ and why?

Introduction

git rebase example scenario

Try to fix it manually

Use ‘git rebase –skip’ to skip the commit

‘git rebase –skip’ vs ‘git rebase –abort’