Submitting multiple pull requests in a row causes commits to be added to the same PR

1.  Introduction

So, I was working on a feature branch of a forked repository and was about to push that branch in order to create a pull request out of it.

I develop my changes, test, commit, push the branch and create a PR.

2. Situation

However, while working on the fore-mentioned feature branch, I also noticed that another PR was needed. I’m working with IntelliJ, so, I at some point noticed that the git ignore file of the project didn’t include any mention to specific IDE-generated files

3. Problem

Ok, cool, so, I have to create a new PR, cuz it’s about something totally different.

So, checked out a new branch, committed the changes, pushed the branch and…

What? Why my newly pushed branch is 2 commits ahead of master? I just pushed one commit!

Side note here is that if I create a new PR based on this branch, the changes of my first PR would still be included. So, I have to somehow remove them, synchronize my gitignore-branch with master and then push the branch again, by erasing the previously logged history.

4. Solution

Oke, lemme check:

Pooooh, of course, when I checked out to a new branch, I have already pushed my first branch, so the newly created branch has on top of its HEAD the latest “local” changes. Let’s reset it back to a valid remote state. That is, just after cloning it:

I’m on the branch which has to do with the update of the .gitignore file, so I only wanna add the .gitignore file ot it and then force the push, so that I erase all the previously existing history of the tree and have a single commit displayed to my branch ( and my PR, of course):

5. Confirmation




Beautify your git history by rebasing

1. Introduction

percircle is a project I started on 2015, without having a clue about js (which is still valid :-P), but of course, there’s always place for improvement.

Today I noticed that I was creating a dirty history with several small unnecessary commits, so, I thought about experimenting a bit.

2. Situation

Below you can see a not-so-nice history of 4 commits. What they actually are about is 2 commits for the readme file and a corresponding release to npm for each one of them. But those two changes could be displayed as one, since only the latest is the one that contains the proper changes. So, I wanna somehow erase commits f13df6d and 12632de.

3. Solution

For this, I will be needing the help of git rebase. Specifically, I wanna rebase on top of the latest release, prior to any changes in the readme file. That is, the commit for November 3:

git rebase -i e1a7e698d399b51cfd2cf283e0ff25d8aa23175c

I then just “drop” the commits that I don’t wanna be included in my history anymore and totally be deleted:

I save the file and I see that there’s an issue:

Hmmm, let’s see what is it about:

Ok, let’s go heck what is wrong with this version (I suspect it has to do with versioning):

Indeed. Ok, lemme:

  • keep the proper version
  • resolve the conflict
  • continue rebasing and
  • force the push

The most important part of such a rebase is to eventually force the push, so that a rewrite occurs in the history’s tree.

4. Result


Happy King’s Day!