The superpower to perform version control on reality. (Git)

Imagine this universe (the current branch), which is made up of a series of events (commits).

Having this ability to allows us to:

- undo events (git reset/git revert)
- reorder events (git rebase)
- transfer to another universe (git checkout)
- derive a new universe from current universe (git checkout -b)
- delete a universe (git branch -D)
- apply an event from another universe (git cherry-pick)

and my favorite:
- merge universes and their events (git merge)

we have to resolve conflicting events, of course.

What else? ;)

!rant.
Here's some useful git tricks. Use with care and remember to be careful to only rewrite history when noones looking.

- git rebase: powerful history rewriting. Combine commits, delete commits, reorder commits, etc.

- git reflog: unfuck yourself. Move back to where you were even if where you were was destroyed by rebasing or deleting. Git never deletes commits that you've seen within at least the last 50 HEAD changes, and not at all until a GC happens, so you can save yourself quite often.

- git cherry-pick: steal a commit into another branch. Useful for pulling things out of larger changesets.

- git worktree: checkout a different branch into a different folder using the same git repository.

- git fetch: get latest commits and origin HEADs without impacting local braches.

- git push --force-with-lease: force push without overwriting other's changes

I think the reason why git beginners have a hard time with it is because the api is a bit untuitive.

For example: if you want to "unstage" staged changes, you run git reset, and if you want to "delete" those changes from your working copy, you git checkout those files.

But then, you find out that you can do all of that if you git add . and git reset --hard.
So you're like "huh..."

And then you discover that if you end the resethard with a branch name/commit id then you also make current branch point to the commit or that branch/commit (respectively).
So you're like "huh..."

And also if you add a commit id or branch name to git checkout, you change the current branch to specified/enter detached state with HEAD pointing to that commit (respectively).

Oh and you don't use git branch to create branches, you use git checkout -b because it's a lot shorter.

So here's a rundown: git reset mutates things related to files, but also mutates things related to branches.
git checkout also mutates things related to files and mutates things related to branches too (in a diff way). Also, creates new branches.

I don't think this is intuitive. We users use the same commands for different purposes with just a different flag.
Commands shouldn't mutate different types of things. But don't composite commands (as in, "smart" commands that mutate different things) shoudln't be a flag in an existing command, it should be a single new command of its own.

Maybe if I reread the internals of git now, I'll be able to disgest the dozens of technical terms they throw at you (they are many). And in my mind, the api will cognitively fit to the explanations.

Here's another one that feels weird too.
If you want to make your changes start on top of someone else's commit, you do git rebase.
But git rebase -i can be used for that, and also to delete, modify changes or message of, reorder or combine previous commits of the current branch.

Maybe the reason why several things we do overlap with the same commands is because they internally do similar things, and while not separating those commands might make it less intuitive, it makes them more sensible? i dunno...

disclaimer: I'm not setting this opinion in stone though, and am aware that git was created by one of the most infuential programmers.

git rebase is like fish.

Hours after the kill: hmm, tasty.
A day after the kill: not too bad.
A few days: time to toss this in the trash
More than a week: dig a hole and bury this thing before it stinks up the neighborhood.

That being said, I'd rather eat a plate of Hákarl than deal with rebasing a diverance that is over a month old. I simply don't use rebase. It's just too stinky. I just merge very often and keep things in sync.

If you need the effect of a rebase without the crazy hassle:
git checkout master
git checkout -b rebase_branch
git merge --squash dev_branch

Can someone tell me how to properly rebase changes from main branch

I always fuck myself over. Fucking merge conflicts i caused by myself. Since the CD pipeline creates a commit or i merge into main from a side branch, i often forget to pull those changes locally from main branch

What happens then is i just create a new branch to start working on the next feature

git checkout -b feature/shit

Totally forgetting to first do

git pull --rebase

From main branch. Because of this when i push shitload of features to feature/shit branch and then try to merge that shit into main. CD pipeline gets fucked. There are merge conflicts now because i havent rebased

Question -- if i switch to a new branch, make a shitload of changes and forget to rebase from main branch First, what command do i type to rebase right there (on the new branch) but rebase from main branch so these conflicts dont appear?