Is it me or Git rebase is kind of hard to understand?

It's not. Just spend some time thinking about it not as a command to execute, but rather as an operation on a data structure you're working with (which is your repository) and it will click.

Git appears to be a tool to manage merges using deltas. Git is actually a tool that simply stores everything in the current commit, and makes a nice graph showing Connections between those commits which theoretically represent deltas.

All trouble arises when this abstraction breaks. It seems to me that the purpose of git merge is to simply allow you to work around broken abstractions. You can make the graph appear how you want, without having to jump through a bazillion unnecessary hoops to make a nice set of deltas.

Or... I'm wrong and about to find out after hitting "add comment"

I'm the opposite and think rebasing is easier, but I am biased obviously since I have only used rebasing to solve merge conflicts.

There are a couple ways of performing a git rebase, namely

* git rebase

* git rebase interactive (git rebase -i)

* git rebase --onto

I think following these videos may help and will explain it better than I can.

What is Git Rebase? [Intermediate Git Tutorial] - https://www.youtube.com/watch?v=_UZEXUrj-Ds

Squashing Git commits with Interactive Rebase -https://www.youtube.com/watch?v=7IfkL8swmFw

How to undo git rebase using git reflog. - https://www.youtube.com/watch?v=qP4i3S2hujc&t=203s

Everything Git is kind of hard to understand, but once it "clicks", you kinda start thinking it was easy all along.

My suggestion is: before every rebase:

- mkdir patches

- cd patches

- git format-patch HEAD~30 (in case you had 30 commits on top of the main branch but you can also "git format-patch $SHA" to get patches up to that SHA, not including)

- git pull --rebase

Then, if the rebase fails:

- git checkout -b branchname-rebaseattempt origin/branch

- make

- git am 0001*

- make

- git am 0002*

- git am --abort

- etc

This way you have a backup copy of every one of your commits as a patch file, and you can better understand and fix your conflict step-by-step without being "locked" in the process of a git-rebase. Sometimes when there are simple conflicts I edit the patch files themselves before applying.

Hello everyone, I have some wise advice that will help you if you want to unwind and have a nice time. For instance, https://grantubodesexo.com/ is perfect for a night out because it allows you to let off steam while having fun. I think you should have a look.

"Within a converged timeline there are two timelines of events, so to create a new non-converged timeline you have to go back to the point in time where those timelines converged and add every event in the converged timelines in order in the new timeline.

If things don't really work and a conflict emerges you, as the master of time, have to decide the right data to put into the new timeline"

Hope it helps you breathe more easily :)

How the hell is it mysterious? It is just cherry-picking the commits then setting the branch pointer. Merge is the evil one because you can hide any changes you like in the commit.

Git is a good idea with a poor execution and naming