The Rebasing Adventure: Chapter 1

There was an island deep deep far far away, hidden away. It was littered with dangerous and poisonous snakes. Green snakes. Pythons? In the middle of that island there was a little red wooden shack on top of the hill. And in that shack lived... me. 

And in order to escape the valley of the snakes littered afraid all over the little island and to make the desert island safe again... I had to learn REBASING. At least that's what I told myself anyway.

Brazil's real-life 'snake island'.

Must it really have to be as scary as that?

The rebasing journey so far

My work values neat, ordered commits. This makes it easier for the developer reviewing your pull request to handle it. So you want your code to be in atomic commits - each code does one thing and is self contained. Each commit should also do things properly - no commits going back and randomly fixing things and breaking things.

So the problem here is that this requires rebasing.

I did try and cover rebasing with a lot of Senior devs at my previous workplace. But 2,3 of them... we couldn't make it click. This is unusual for me.

Maybe I am just overcomplicating it. "He who controls the past masters the future". To take a George Orwell quote...

Rebasing is just a tool to re-write your commit history... 

Steps so far:

I paired with a senior developer from work online:

It was really amazing as he showed me lots of his stuff. He said that we could pair again when it was actually my turn to do something. He also said that we could pair again when he was doing something similar again, but slightly different. He helped me to get more of the context around WHAT REBASING ACTUALLY IS - re-writing the past - AND WHY WE ACTUALLY DO IT. Most of all it was interesting just to watch him in process and watch him work. I FEEL AS IF ALL OF THE INFORMATION AND CONTEXT OF WHAT HE ACTUALLY DID WILL BE ABSORBED IN TIME.

I asked on two Slack channels:

I asked on my team one, especially for pairing opportunities.

As a result 

• I paired with the amazing Senior developer above - it was so awesome :-)))
• I will pair with another Junior next month
• I got sent some useful links - I will post these to my daily personal log, as these are internal channels
• Note today's date
• 22/4/24

WE HAVE TWO INTERNAL NOTION PAGES THAT LOOK USEFUL. I WILL SAVE THESE FOR MYSELF.

I also asked on the general company questions channel:

• I get sent sent some really useful commands that I will save on my Slack threads, for reference they are
  
• git rebase -i
• git reset --soft main
• Specifically:
• One technique is to use: git rebase -i
• Another is to:
• Rebase onto latest master/main
• git reset --soft main to reset to main with no commits
• unstange changes and restage in chunks to make the commits look better
• Some people like to use GitKraken for the GUI
• I got told PyCharm has great GUI tools, but I don't get PyCharm. 😭

Other tips:

• A staff engineer told me to "make a copy of your branch so you don't get too nervous about messing things up."
• He also said something I love: "I would also suggest pairing". I LOVE PAIRING!!! Thanks.

The principal engineer sent me his blog:

It looks great, I can't wait to read it soon, omg.

Later on...

I just got so confused so I asked a lovely Senior Software Engineer who was sitting next to me in the office. :-)

Asking the senior software engineer next to me

Replaying your commits on top of your target branches HEAD.

(Any branch - the HEAD is the top of branch).

He recommended this page

From this website:

Here's a nice long page:

But it's too long for me to read now - sorry