git/github organization

[mxdubois]

Hey everyone,

Team Repos

I talked to Joel and I think we're probably going to want to break each team off into their own repo for now, then work on combining code into one repo as necessary later on. Joel's given us all permissions to create repos -- so go ahead and create a repo for your team if you don't have one already.

For simplicity's sake, I'd recommend making team repos with a lowercase, hyphen-separated name. This seems to be slightly more common out in the wild. Git branches are also commonly given names like this -- so I figure it's as safe a convention as any ... but it's up to your team. (It is definitely less confusing if we all do the same thing though.)

Git Flow

I've found this git model to work really well: http://nvie.com/posts/a-successful-git-branching-model/

Unless anyone is opposed, I'd recommend that we use it. It won't matter as much for the main_trunk right now, but you might find it really useful within your teams. (Ultimately, it's up to your team what you use internally.)

If you decide you'd like to use it in your teams, there's a git plugin that automates a lot of the branching tasks. More info here:

• https://github.com/nvie/gitflow/
• Installation: https://github.com/nvie/gitflow/wiki/Installation
• Usage Instructions: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

main_trunk

Though we will all have separate team repos, this main_trunk repo will act as our hub for inter-team issues and wiki pages. Module-specific documentation should probably go on the wiki's in your module's repo.

Following the git-flow model, I created a branch called 'develop' to act as our main development branch on main_trunk. This branch should always represent a working development copy of whatever we having going. The master branch will then be reserved for our finished release(s).

Looking ahead, I think we'll probably want to merge repositories as git submodules (if, in fact, we decide we need to merge them all together someday). You can read more about this process here:

• http://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories
• http://git-scm.com/book/en/Git-Tools-Submodules

Forking

Since we're not open-source, we shouldn't need to deal with forking. Everyone in the class has been granted access to the repository and can make changes directly upon it. Therefore, you shouldn't need to fork main_trunk or your team's repo. Just clone your teams repo to your local machine, branch off your teams develop branch to work on a feature, then merge the completed feature back into develop, and push to github.

(If anyone has a strong argument as to why we should all individually fork the main or team repo's, let us know in the comments.)

Any Thoughts or Comments?

Let me know what you guys think. If you see any problems with this approach or know of a better solution, please voice it in the comments.

Thanks!

[nburns]

git-flow looks pretty slick.

[matthewcburke]

That all seems good. Thanks for taking the initiative to make the suggestions! I'll try to get the AR team on-board.