I fork you, I really do.

August 23, 2011 10:58 AM

Can you please help me figure out some issues regarding Github?

I've used git as my version control system for a while. It's simple and easy to follow. However, I have primarily used it on projects where I am the sole author. A few months ago I actively started using github but am still having a hard time wrapping my mind around how collaborative coding works.

I understand that I can fork a public repository, work on it, and then do a pull request so the original author can have the option of incorporating my code into the master. But I am in a situation where I am working on a series of projects with 3 other developers. All of us have read-write (admin) acccess on all projects. In plain English, how would this work?

I synchronize a copy to work on.
I edit code, commit changes, and push to remote
James work on it and pushes to remote.
Bob is also working on code at the same time.
What happens to conflicts?
Are we all writing to the same branch?
Do I have to grab a new copy every time I do some work?

PS: If you have other resources to help me use github like a pro, I would very much appreciate it. I don't have prior experience with other version control systems so that would be something to keep in mind.

posted by babbyʼ); Drop table users; -- to Computers & Internet (9 answers total)

Best answer: Disclaimer: I'm a n00b at github, but I spent a lot of time at my last job working with version control systems.

What happens to conflicts?

git should give you a message when you're making a merge with conflicts. At that point it's the job of whomever is making the merge to resolve the conflicts manually and then resubmit. It's usually pretty straightforward to figure out which bit should make it into the merge, but if not you'll have to talk to the other person who's worked on that file.

Are we all writing to the same branch?

Depends on how you set it up. For relatively minor changes, or for changes where you're all coordinating closely, a single branch is fine. If you're making major and potentially very disruptive changes, though, it's usually best to work in a separate branch so you can make sure all your work is kosher without hosing everyone else.

Do I have to grab a new copy every time I do some work?

If not every time, then pretty damn close. This will save you major effort when it comes to integrating your changes, and prevent you from doing some really dumb things like nuking several weeks' worth of other people's work. (Not that I've done that.)
posted by asterix at 11:11 AM on August 23, 2011

There's numerous ways to build a workflow with git and GitHub. In your case, I would recommend having a single member of the team handle the main master branch of the project. Each developer would clone the repo and create feature branches off of the master branch. As code is checked in, the master branch maintainer would merge in the changes from the feature branches and handle the conflicts, and the other developers can then pull the changes from the master branch into their working branch as code goes to master.

You should definitely be pulling and pushing code as quickly as possible to keep your branch up to date. It will lessen conflicts considerably.
posted by ndfine at 11:17 AM on August 23, 2011

Oh, and having spent a little time browsing through it, the Git Reference looks decent.

One other thing: MAKE SURE YOU WRITE MEANINGFUL COMMIT MESSAGES. As one of my friends said, when you write a commit message, say *why* you're committing, not *what* you're committing. There's nothing worse than trying to figure out, months later, why someone chose to check something in.
posted by asterix at 11:25 AM on August 23, 2011

If everybody is working off of master, conflicts will be spit back at you and you'll have to clean the problematic files up and re-commit a "merge." Other than that, my workflow has been something like: git pull (get recent changes); make my edits; git pull (again, update); git commit; git push.
posted by rhizome at 11:50 AM on August 23, 2011

Best answer: Git is happy to work with whatever workflow you choose, but I tend to follow the below, generally speaking.

// update
git pull origin master

// new branch
git checkout -b a-feature-branch

// make changes
<develop stuff>
git add <changed files>
git commit -m "doing stuff"

// update and rebase (optional?)
git checkout master
git pull origin master
git checkout a-feature-branch
git rebase master
<fix conflicts if needed>

// final update
git checkout master
git pull origin master

// merge and push to origin
git merge a-feature-branch
<fix conflicts if any>
git push origin master

Rinse repeat for different features/change-sets.
posted by wrok at 12:08 PM on August 23, 2011 [5 favorites]

I got dropped in over my head with git a few months back, working with a team who was well-versed in it whereas I'd only used it for solo projects. The team has been a great resource and it's amazing how much easier things can be than Subversion (in terms of branching, etc). That said, it took me a long time to get comfortable and it seemed overwhelming. Pro Git helped a bit to understand the workflow options. That's where I got lost for a long time. The (slightly simplified) way the two teams I've worked with use it looks a lot like wrok's advice:

• check out the master
• create a branch for what ever single feature you're working on (braching is cheap, so you don't need to make monolithic branches (or just work in the trunk))
• work on your branch
• commit as needed
• push
• switch back to master to make sure you don't branch your next branch from your original branch and look like a complete idiot like me

posted by yerfatma at 2:02 PM on August 23, 2011

Best answer: I've been using git for a while, and there's a lot I can say. It's probably better to read through a few things first, though. I'd suggest checking out The Git Community Book. As far as workflow goes, see the original git-flow post.
posted by cardioid at 9:02 PM on August 23, 2011 [2 favorites]

Best answer: Git is excellent, but it is by no means as obvious as some people make it sound. My recommendation, which is what I believe many serious git users also practice, is to rebase your commits onto the latest master before pushing your changes. This is different than the "default" strategy of pulling master, merging your changes, then pushing the changes plus a merge changeset. The latter becomes real ugly, because you have revisions that are based on ancient history, and you get merge commits which contain no useful information and just add noise to the repository history. I don't have links handy, but some googling will find all sorts of discussions and arguments about rebase. It's the right thing to do. This also makes you responsible for producing change sets that apply cleanly, instead of someone else managing pull requests. I think that is a good thing.

This is all separate from the question of branches. I like the page understanding the git workflow for that, but it might be more than you need right now.
posted by kiltedtaco at 9:32 PM on August 23, 2011 [1 favorite]

Best answer: The IRC channel for git (#git on Freenode) is full of ridiculously helpful people.
posted by vasi at 12:52 PM on August 24, 2011