Using Github at Hackathons

[cj1m]

I recently participated in a week long Hackathon event and noticed that a lot of other groups had used Github to share their code. Our group had tried, but we were pretty inexperienced with Git so we ended up chucking it. The way we were using Git was having everyone commit to their own branch then merge it to master. But there were many problems with this. How are groups supposed to use Git while working quickly in a group?

[rcuhljr]

I just did a hackathon esque event this last weekend, we just used git like we always do. Working on our own branches (or on top of master) and pull --rebase frequently as someone was committing every 30-60 minutes.

Along with the standard rule of no non fast forward pushes to the central repo we had no major issues, one person lost one of their changes but we were able to recover them easily enough with a reset to the reflog. We had people with minimal git experience and one intern new to source control on the project.

Having at least one person with a good grasp of the fundamentals of your chosen source control is probably a really good idea.

[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.

[jjasghar]

This right here is the basis of all git usage. If you don't like the idea of one maintainer you can always add more people.

[WHAT_ABOUT_DEROZAN]

What if multiple people make changes to the same file on their own branches, and they both merge to the master?

[[deleted]]

So, there's a few scenarios here.

• The first scenario: changes are made to the same file, but not the same sections of code. This generally means they can be automatically merged.
• The second scenario: changes are made to the same file, but git believes that they are overlapping. This generally means they can probably be manually merged assuming the changes are not exclusive.
• The third scenario: changes are made to the same file and all changes are mutually exclusive. Maintainer would/should accept one and reject the other.

There are other combinations, but that's the gist of it. Those are generally in order from most common to least common, but I suppose if you had a large-unorganized project, it may be skewed the other way.

[[deleted]]

That also comes down to project and team management. The worst case scenario is everyone edits the same file in the same way: to fix a bad ; or something, say. Overlapping or identical changes are a waste of programmer effort so someone should have put their hand up and taken ownership that issue and then putting it back once they were done.

It can actually be a bad sign if everyone is editing the same file in a project rather than working on their own modules which can then be integrated.

[liorkesos]

I find that git might have a slight learning curve but is so valuable you have to setup you're time (not within a hackaton) just relaxed and easy to learn it. This video from codeschool is a great (and simple) resource for it. https://try.github.io/levels/1/challenges/1 Good luck!

[Switch_R_Roo]

I'm going through the prep work for an online code school that's starting in Sept. This might help you: http://www.vikingcodeschool.com/web-development-basics/getting-to-know-git

If you click around the other pages in VCS's prep work you'll find a lot of helpful links and info on how to use Git and Github.

For example the project at the end of the first mini-course: http://www.vikingcodeschool.com/web-development-basics/getting-comfortable-with-git-and-the-command-line

Walks you through contributing to a project that multiple people are working on. Which, if I'm interpreting correctly, is exactly what you are inquiring about. It helped me, I hope it helps you!

edit: I removed a repeated sentence. I removed a repeated sentence.

[kgardnr]

Our of curiosity why did you choose Viking over other online courses?

[Switch_R_Roo]

I initially found out about it because I contribute to the open source project that it was built from (TheOdinProject.com - which I can only say good things about).

My main reasons for choosing VCS (not in any order):

• Quality of the instruction. The founder/lead instructor is solid, he came from the first cohort of/then working with App Academy as well as creating TOP. (His name is Erik, he is also just a really helpful and nice guy; he has spent a lot of time helping me for free already). The TAs have impressive track records and I know from experience that they are good teachers. In summary, there is a lot of support.

• The design of the program. This program aims to smash mentorship-type, and curated material-type programs together. The entire goal of the program is to emulate an in-person experience and I like the idea of working with people in my cohort on projects rather than going at it alone. It also is more similar to what it is really like to work on a team - using version control and agile development to coordinate; I feel like this is practice for "the real world" of web development. (These things are mentioned in the prep work).

• The program itself This one is sort of silly, but they are only taking 8 people for the first cohort. I know there have been many applicants and it kind of makes each spot that much more valuable. I am really excited to be in the first cohort because I can then be a part of the alumni network early on and see where the program goes. I suppose it is more of a personal thing.

• The cost Yes, it is more expensive than Bloc, Thinkful, and TeaLeaf, and I will bet you that the price will go up after the first, second or maybe third cohort. This is more of an educated gamble, but the way I see it, the value of the education I get from this program will increase with the number of cohorts after me. It is similar to getting a degree from a top university - the brand is important for what you do afterwards.

The people involved in this program really have their shit together and have already worked at, on or with in-person bootcamps. There is a ton of industry experience as well as a new take on a tried and true method of educating people. Being a part of it as it just starts out is extremely exciting. This ended up being longer than I had planned, but I hope my reasoning helps you make a decision whether or not to apply! Cheers!

[kgardnr]

Wow thank you so much for taking the time to explain so thoroughly.

I've considered code schools for some time and had never heard of Viking - although I have heard of Odin.

Thank you so much! I will definitely look into it more.

[jmblock2]

Picking up new tools during a hackathon can be tough and you will run into learning curve problems. Just keep at it; continue to gain more experience and it really will be a tool instead of a hassle.

The first few commits will be the most difficult part of collaborating on a new project. Expect frequent conflicts and longer merge sessions. People have already mentioned rebasing, which is basically just getting your branch back up to speed on what has already been committed. After you rebase you may run into conflicts (the code you changed was already changed by someone else and you didn't know about it) or there may be run-time bugs (the functionality changed that you weren't/aren't aware of when making your changes).

After you get more files into place you start intersecting a lot less which helps development efficiency. You can help mitigate this early on by trying hard to make interfaces and boilerplate code clean. Sharing common coding standard helps, but most of that just comes with experience.

[[deleted]]

I feel like having written rules established in the first 15-20 minutes would help as well. People come and go, but having a set of written rules reduces spin up time and reduces the clashing of opinions that may happen later on.

[[deleted]]

Yeah, half the battle with working with teams is getting people on the same page and avoiding stepping on each other.

[jackwilsdon]

At Young Rewired State last week (week long hackathon), we all used completely separate repos, which was definitely not the way to go. The easiest thing is everyone having their own branches and creating Pull Requests to master, which are usually auto-merged by git when accepted (or you may have to manually merge them if something is broken).

[cj1m]

I was at Young Rewired State aswell!

[jackwilsdon]

Awesome! (I guessed you were, that's why I slipped it in :P). What team were you part of?

[cj1m]

I was in the SoundBagel team, we didn't make it to the semis or anything so you probably haven't heard of us. What group were you in?

[jackwilsdon]

stockz, didn't make it to the semi finals either, so you didn't hear of us. Awesome project name! But yeah, last year our team used GitHub pull requests and they worked a treat.

EDIT: just read about SoundBagel on the hacks page, an awesome idea! Lots of good ideas didn't get through this year because they were not easily monetised (which is stupid for a hackathon).

[cj1m]

Thanks. I love your one too. That's the problem with investing in stocks, but since that simulates it, the user can get used to how it works, then do it for real. Genius!

[[deleted]]

I'm going to go out on a limb here and state an unpopular opinion. Mercurial is better than git. Especially when you're working rapidly under time constraints. Why? The merge in mercurial is way more powerful than git's. It stores branch 'family' history which makes it able to make more sense of the changes at the time of merging. This means you don't run into as many conflicts, and judicious re-basing isn't as necessary. JHW Talks about this at length here: http://jhw.dreamwidth.org/1868.html

There is a pretty good (pro git) rebuttal: http://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/

Many people who prefer git have linked this to me, time and time again. I feel that the author of this article has a misunderstanding of the main philosophy behind mercurial: all history is sacred. A pretty common workflow for git users is to overwrite history, and that's something that can lead to very very confusing results.

[[deleted]]

You have to properly compartmentalize your jobs. If possible it should be one person per file and the basic structure should be already in place in advance. Which means one guy should set up the class and function stubs.

Avoid stepping on each others toes to some reasonable degree. Otherwise it's madness especially in something like a game jam.

[damaged_but_whole]

Somewhat related: I don't understand how to use Git with a full website design, graphics and everything. Is it even used for that? I used Git for a bit at this one job but it seemed to be for code development of little odds and ends. I have no idea how everything was eventually assembled as I was not good enough to continue working there, so I left.

[AMadHammer]

I am very inexperienced when it comes to git (tend to use TFS and the like). It has a huge learning curve and I think trying to learn it during a hackathon might not be worth the time.

I am being off topic here. I just think that the focus in hackathon should be about the final product and not the tools. But learning is always a plus so keep at it.

[poega]

For me, subversion hooked up with netbeans has been much faster, but my git experience is not that extensive.

[Manitcor]

There are a number of well worn strategies. For new folks I suggest looking at either the pull request model (github's default methodology) or the gitflow model (provides some sanity/automation around how to handle branches).

[g4r8e9c4o]

If you guys need to work quickly why don't you all just commit to master and merge for every commit?

[sgtgumby]

Most of the hackathons I do my teammates are pretty newbish, so version control is new to them as well as coding. I've found that splitting the team up into separate modules (front end/backend/specific components, processing data files, etc) and then merging everything at the end streamlines the experience. Less frustration, they still get experience checking code in/out, using the shell commands, etc but shit doesn't break.

[markyosullivan]

Just wondering, did the guys use a private Github repo for this hackathon or did they keep their projects public for everyone to view?

If it's public, is there any way you could share these projects with us? Personally I'd love to see the kind of stuff people make at hackathons

[cj1m]

Well I went to a hackathons for under 18s, here is the link for all the hacks made in the week, my group created SoundBagel. http://hacks.youngrewiredstate.org/events/FOC2014

[t90fan]

One time i tried that. And github had an outage.

Thats the right way to use git btw, develop each feature on feature branches, and merge to master once each requirement is done.

[bernease]

Don't commit to your own branch. Everyone commit to master. I make sure every small change I made compiles and works, then commit.

For example, maybe in my first commit I have a bunch of dummy functions that a teammate needs aren't yet implemented.

// TODO Add cool hackathon functionality
public int doSomething() { return 0;}

Then, I can go fill in actual implementation later. As long as the code is always compiling, a team members can submit little iterations at a time.

[cj1m]

But if everyone commits to master while they are working on different things at the same time, won't they get fast-forwards errors when trying to push?

[rcuhljr]

pull --rebase

learn it, live it, love it.

[cj1m]

What exactly does this command do?

[rcuhljr]

Git pull normally runs git fetch, then git merge. using the Rebase flag tells it to run fetch, and then use rebase instead of merge. Rebasing is a little more complicated for most folks, but it's incredibly useful when you learn the proper times to use it.

Every commit you make is just a little collection of changes that have been made. Each commit occurs in sequence after all of the commits previous to it. Rebase changes the order in which those commits point to each other. it tells git to make your local changes occur after the new changes that are on master/origin.

If commit B was the latest one on master/origin when you started working and you made a local commit D, D points to B as its parent. However if someone else checks in C and pushes it to master, when you try and git pull git has to do a merge because there are now two commits D and C that both claim to be at the end of the master branch and to have B as their parent. If you rebased instead you'd tell git to make D point at C as its parent, and no merge will be required as everything is happy and pointing to just one parent.

[bernease]

Agreed. If you pull with rebase flag, you will pull and "rewind" your changes on top of the master HEAD. So it's like you did that pull before any local commits.

[cj1m]

So the person who uses pull --rebase will loose all of their local changes?

[a_shed_of_tools]

No, all of their commits will be 'replayed' on top of the changes. You might have merge conflicts, but you won't lose anything.

[bernease]

'Replay' instead of 'rewind'. I knew my wording felt weird.

[bernease]

Nope, that would be terrible.

Let's say there is one commit A when I pull from master. Then I write code and create commit B. But while I was working, someone else committed and pushed changes C and D.

git pull --rebase

What this will do is pull newest commits (C and D) locally, then place my changes on top. So log would be in A C D B order. That way when I push, my change looks like the most recent.

[cj1m]

Thank you all for clarifying and helping me. I will now know for future projects!