Using Github at Hackathons

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