branch-protection and a peek under the hood of force-pushing

Conversation started Sep 4, 2015 at 16:33.

Vogel612

Sep 4, 2015 16:33

Hya

have you guys read about the new "Branch Protection" feature in GitHub?

Zak

nope?

Vogel612

It allows you to disable force-pushes to selected branches in your repo

Zak

What's a force push?

Vogel612

which is a way to protect against intended or unintended data-loss

Zak

Asides from an obvious Star Wars pun ofc.

Vogel612

Sep 4, 2015 16:44

ooh dear

okay you know about git?

Zak

yes, I'm relatively new to it though

Vogel612

please sketch roughly what you know, so I can pick you up

Zak

in terms of projects/collaborations

Vogel612

no. about git itself.

branches, commits, pulling, pushing and merging

Zak

oh, right, I know it's the software that powers GIThub

yeah, yeah, I'm getting to that

MAster branch

whenever you commit, you update with the latest code

Vogel612

Sep 4, 2015 16:46

hmm. I'll have to start at the start then.

Zak

so every commit revision is documented and can be reverted back to

you can branch off

Vogel612

force-pushing goes a little into depth.

Zak

and then request to pull that back in

Vogel612

correct.

Zak

I had no idea there was anyway to force-push a branch though

Vogel612

Sep 4, 2015 16:47

now to what a force push is, and when you need it.

A commit is uniquely identified by it's hash

The hash is calculated from multiple things, for one from the commiter's username and email

also from the commit message and the content it contains

and also from the "parent commit hash"

now this allows you to do a few cool things

a commit in itself always allows you to verify the integrity of all commits before it

meaning: nobody changed a commit you have made x days ago. Because then the hash changes, and suddenly it doesn't fit together anymore

with me so far?

Zak

yep

Vogel612

okay now the cool part.

Zak

didn't know you could edit historical commits either

Vogel612

that's where the force pushing comes in

quick sidenote: A branch is a label that points to a certain commit hash

keep that in the back of your head

now. We can go back to a specific commit in the history, by using git checkout [hash]

this will get us into the so-called "Detached Head State".

if you're interested in why it's called that I can tell you, but it's not relevant right now

aaaanyways. You can now change that commit, since this is the "latest" commit for you

let's say you do some malicious changes to the codebase

to get these into the repository, you must stage then and then you can run git commit --amend

As soon as you do that, something happens with the commit.

The hash changes, since the changes you did are different now.

this is extremely important

now. You have this branch that the commit belongs to.

(for simplicity let's say it's the master)

now you want to make your changes appear in master.

to do that you have to replay each single commit between the revision you originally checked out and the tip of the branch

so far so good?

Zak

I think so

Vogel612

Sep 4, 2015 16:57

okay then I shall continue.

Since the commit hash of the commit you compromised changed, all other commit hashes after that also change

do you remember why?

Zak

yes, because they're all based off of the historical hash chain

Vogel612

wonderful, you understood it

now what we want is to have this appear in master

this means we move the label master from the tip of the original master branch to the tip of the compromised branch

When we now push that branch to our github repository, something cool happens.

github (or more correctly git) rejects the push.

if you want to update a branch, the old tip of the branch must be in the hash chain of the new tip

if it isn't the update is rejected.

unless you force-push

Zak

okay

but why is force-pushing even allowed then?>

Vogel612

because there are actual use-cases when you need to rewrite history

accidentally committing sensitive information being the most prominent

Zak

could you try and explain some of them?

Vogel612

Sep 4, 2015 17:07

well consider you develop some feature over a few commits

and then you realize: "Whoops that second commit I did, contains my password for github"

what do you do?

Zak

I see

Vogel612

alternatively there's a cool feature called rebase

if you are developing by a certain workflow, you may have to rebase regularly before merging into master

Scenario:

There's 3 devs on a team. Let's call em A, B, and C

now A starts working on a really really really big feature (like rewriting the GUI or sth.)

what they do is they branch out at some point from master

then development continues, developer B and C perform significant changes to the codebase, and after 2 months or so, developer A wants to merge their feature

since developer A wants to know their work safe, they commited the working state every evening to the branch GUI_REWRITE

and because they don't want the codebases to become too divergent (which makes merging something devs are scared shirtless of), they merged the changes from master every 3 days

this means they have at least 40 commits now.

the day of the pull-request comes and devs B and C review A's work

to simplify this process the company states "review each commit by it's own merit and the whole diff by it's merit"

reviewing each commit often makes it simpler to CR changes

because a commit is a logical unit, and a diff of 2 months development is not really reviewable.

anyways, the pull-request is approved

now: does it make sense to just merge the changes from GUI_REWRITE into master?

Zak

I have no idea where you'd even start with that :)

Vogel612

If you do that, all the commits for that feature will be scattered across the whole history

and that makes it hard to go back and revert them if something goes wrong.

also it's difficult to trace them back to the rewrite

because of that the whole GUI_REWRITE branch will be rebased.

this means the changes you do for that branch are replayed onto a different branch

Zak

Sep 4, 2015 17:23

okay

Vogel612

in that process you can do cool stuff with the commits, like reordering, packing multiple commits into one commit and things like that

that's advanced though.

in any way, suddenly the GUI_REWRITE has a different hash-chain and suddenly you need to force-push again

Zak

I get it

so the new option means that nobody can force push unless the owner of the repo specifically allows it?

Vogel612

no, the other way round

you can still force-push, unless an admin of the repo disallows it

Conversation ended Sep 4, 2015 at 17:27.

View all rooms

branch-protection and a peek under the hood of force-pushing

Sep '154

VBA Rubberducking

This chat has moved to Discord: discord.gg/MYX9RECenJ

context of the conversation
join this room
about this room

Participants

Vogel612 76%
Zak 23%

all times are UTC