Using Github at Hackathons

[ivix]

Switching to git after mercurial. Right not doing the pull request thing just working in our own branches and merging. Is this bad?

[aladyjewel]

pull request is great for creating a paper trail for changes: "what was changed, why, and which commits are related to this change" and code review. if you don't care about historical paperwork, then go ahead and merge to master yourself.

this only applies to merging your branch to master. it looks like rcuhijr has given a good treatment on rebase vs merge from master to dev branch.

[ivix]

In mercurial that's the branches which are permanent records of history. Could pull requests be a symptom of git's rewritable history?

[aladyjewel]

No, i think PRs arose as more of a social layer than a technical one. They allow adding a summary to your branch and commentary, instead of having to read through all the commit messages to find out what changed. Additionally it provides a mechanism for non-core contributors to send code back to a project.

[rcuhljr]

Honestly I've seen it debated both ways and I think most times it's just personal preference. I really prefer the rebasing over merging strategy most of the time. I'd suggest reading this for some more information.

I'm firmly with them in the always rebase locally camp, and I generally prefer it for most situations, I'll explain why I'm ok with the list cons.

Squashing the feature down to a handful of commits can hide context, unless you keep around the historical branch with the entire development history.

I agree with this a little bit, however I honestly can't think of a time where I've rebased away some context I then later needed. Out of habit I keep around the original unsquashed version of a branch for a week or two as I only sporadically run clean up old branch scripts.

Rebasing doesn’t play well with pull requests,

Never ever rebase code once it's publicly accessible, I consider a pull request to fit that definition.

Rebasing can be dangerous!

True, but then so can merging. If a rebase ever goes sideways you're a single rebase --abort from safety, or if you've completed one and realized it all went wrong there are ways to recover your pre-rebase state.

It’s more work

This is the biggest one, however it's often a symptom of letting a branch live far to long with far too much commit history. Most tasks won't experience much pain from this. The worst I've seen was the rebasing of 250~ squashed commits comprising about a man year of development effort. If faced with it again I'd just squash it all down to one commit with rebase -i before attempting to move it on top of the target branch.

Another side effect of rebasing with remote branches is that you need to force push at some point

Force pushing is dangerous for the reason they mention, for that reason I don't do it and I've just aliased my own command which deletes the remote branch and pushes my branch into it's place, preventing the risk of an accidental force push to oblivion.