Git Hell 1: commit local branch to your personal fork

Welcome to Git Hell, my publication about the hell of Git and how to get away with it.

Sit back, relax, and get angry with me.

If you are lazy, don’t want to read the entire story and you want to jump straight to the solution, click here

Prologue

9 pm: I was sitting on my chair, while chilling with some music. It’s been a long day: I attended my Computer Graphics class and took the bus to go from home to university and vice versa.

I was bored, and usually when I am in this situation, I browse my favorite website: github.com

Boredom leads to creation: we don’t want to be bored, we want to make ourselves active, it’s in our nature

Anyway, I was there until…

Hugo, nice to see you again!

Lights out.

A good, well-known, relatively old project randomly pops into my head.

“Geesh, what’s going on? It’s been a while since I’ve made stuff on this project, let me see if I can do something more”

Of course, did we have any doubt? We can always optimize and add features to our code.

We must pursue our desire to implement these in the most clear, correct and optimized way, because that’s the right way to program.

Git Devil, who are you?

An orange multicolored square was staring on my desk, firmly looking into my eyes.

“Who are you?” – I exclaimed.

“I am Git Devil, the cruel git’s demon. My soul is made up by subtracted time to programmers who try to understand git without reading the doc first, thinking that git will be an easy thing. Btw, I use Arch and you can call me Gevil if you please.”

“Do you feed your soul with users that tries to install Arch?”

“Of course. I heard you started to work back on a nice project of your own… well, well, it seems to be a good time to both of us, don’t you think so?”

“No Gevil, not this time. I won’t stay awake until late, writing code and documenting what’s going on; I must not be in late tomorrow, so my alarm will ring early and…”

But Gevil didn’t want to listen anymore. My words sounded out pathetic and without any apparent logic to them.

It slowly git pushed itself in a dark spot and faded away.

Better work on my project then…

11pm: my work here is finished!

A yawn sound invaded my room: I was sleepy as hell, BUT I did finish my job.

As you probably could have guessed if you read my last article, I was working on a Hugo website.

“I just need to push my commits in another branch and I am ready to go to bed. It’s earlier than normal, so I shouldn’t have problems”

In the distance I hear a cruel laugh: it’s the demon, he’s snickering.

I decide to push all my commits and I realize that… I haven’t cloned the repo! I was working locally on the original repo, not on my fork.

Needless to say, how many insults flew about git: why don’t they have a “noob-proof” web interface? And why do you have to read a guide on how git works? Couldn’t they make it all user-friendly?

But the most important question: how the hell do you transfer commits from a branch of the original repo where you was working, to a local fork?

Should I rebase or should I don’t?

I see a thousand solutions: create a patch to apply to the files (super wrong solution: you don’t record the commits but only the changes), push the branch in the remote and then update the fork and bring back the remote as before (wait: if I don’t have write access, imagine if I can do something like that), but then…

The matter

Basically, I wanted to push from a new branch in a git cloned local repository, to an online fork of the original repo.

Here it is an example of what I mean:

• John creates the repo john/coolproj229
• Milly clones in local john/coolproj229 but doesn’t fork it
• Milly creates a local branch and starts to work
• Milly wants to commit and push on her fork, transferring the commits from the branch.
• She will eventually submit a pull request later on her fork.

NOTE: she doesn’t want to push the branch she’s working on into the original repo.

Let’s open a terminal into the original repo and, after having committed some files, let’s give these commands:

git remote add other git@gitlab.com:username/repo.git
git push other branch:branch

NOTE: username/repo.git must be an existing repo of your own, possibly a fork of the original project (the B repo)

NOTE2: that repo must have the same name as the branch you are currently working.

The end?

BANG. A clear shotgun sound played in the background.

“Gevil” – I exclaimed – “you’re back!”

“Yes, but don’t count too much on it. I am just chilling because you solved this riddle, but now it’s time to deal with SSH keys he-he” and it quickly disappeared

Well, guess it’s time for another bedtime story…

If you loved this article, please, share this story with your friends or write me an email. I’d love to know your thoughts on what I write.