I don't know what I did, but I'm right here in my Git repo:

When I look at the code, I can see that the bdc2ea commit is right after the bdede5 one but I don't know how to make them be on the same line. It will prevent me from further squashing.

From IntelliJ or GitKraken, rebasing is not an option. What should I do to resolve this situation?

CodePudding user response：

That has not to do with you, it is how git works.

I don't know what I did, but I'm right here in my Git repo:

If you notice the last commit in Picture is there probably because you worked on same repo from different machines, or a colleague of you pushed changes while you committed without pulling the those latest changes first.

At some point, you (or IntelliJ, or Kraken, without you knowing it) did a pull and merged those changes in your local repo creating such a commit telling you that you merged a remote branch. That's my guess on why it did happened in first place.

That's how a decentralised VCS should work. If you don't want that, look how to rebase or squash your history so it will look linear.

I suggest you this: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History, and in general I would suggest you to read the whole book as if it were a Novel, you can get a lot out of it.

CodePudding user response：

The cause: git pull

So, I expect the way you created the merge commit fc959b in the first place is that you ran a simple git pull with the default configuration. At that point, bcd2ea was probably only on your local machine, while bdede5 was already on the remote. Now, git pull is just a short-cut for git fetch followed by default by git merge (or git rebase if you change your configuration).

I don't like git pull, and almost never use it.

What you could have done to avoid it

To get that remote change on your machine without creating a merge, and thus keeping a linear history, there are a number of things you could have done.

• git pull --rebase fetches the remote changes and rebases any local commits onto them

• git fetch, then inspect the repo, notice there is a divergence and get rid of it by running git rebase (which is exactly the same operation git pull --rebase does, except you get to see what's going to happen before it happens)

My general advice is to avoid using git pull in the first place. It's what you find in every tutorial and every manual, yet so often it defaults to doing not what you want. git fetch is your friend: it brings in the remote changes locally, which you can inspect, and then you can decide, oh yeah, I want to merge/rebase/whatever.

You can change your configuration to make a rebase the default second operation that a pull does, like this:

git config --global pull.rebase true

but I'm not a fan of that solution either. I want to see what's going to happen, so I always fetch instead.

How to fix a pull (before pushing)

If you didn't (or hadn't) pushed the merge commit fc959b to the remote yet, the local merge was completely undoable and no one would notice.

At the time you did the git pull, you were on bdc2ea, so you can go back there and "try again", sort of. Assuming you have no local changes (git stash them if you do), you can use a hard reset:

git reset --hard bdc2ea

Now if you want to be sure nobody else pushes stuff on remote in the mean time, do git fetch again, and do the rebase:

git rebase origin/pipeline_hooks

(I took the branch name from your logs, but git rebase would have probably worked too since that's likely your remote-tracking branch.)

Now you've got a linear history you can push.

But I already pushed the merge, what do I do now?

Well, now we're falling into the realm of opinion, but you have two perfectly fine choices you can make here:

1. Accept that once a while, a pointless bubble will happen in the history and it's really not that bad (if you work with a team, someone's going to do a careless pull no matter how many times you ask them not to, by personal experience, so I've decided to just live with these bubbles).

2. If you really can't live with it, follow @torek's advice: tell everyone you're going to fix the history, fix it, do a forced push, and tell everyone to reset their work from the fixed branch. And hope everyone was paying attention, because if someone does a careless pull, you might end up with a three way bubble and duplicated commits that you'll really want to fix and force push yet again.