Git-style development

[iduhetonas]

I'm sure we've seen this before, but I want to be sure that we're all familiar with the "git-style" workflow for development.

Git-Style Development

• Only under rare circumstances should we modify the master branch! - Typically, when working on an issue, the proper protocol is to fork a branch from master, name it something relevant to the issue (i.e. Issue #2), and merge when the issue is complete. This saves us from committing half-finished issues to the master just to work on a higher-priority bug.
• Practice writing good comments to commits! - The power of git really comes from our ability to revert, read history, change, modify, and track development. This is all completely useless if we don't practice good commit comments.
• Tags should happen at each milestone! - This one isn't particularly important, but I'd like to treat this project like a software engineering project in industry. Basically, whenever we "complete" a project, we add a number to our tagged release (starting at 1.0.0 for example). This also helps to revert back to points where we knew code worked during a milestone.
• (As contributed by Murph) Close bugs with the issue number! - Pretty straightforward. I assume we'll want this to happen on the commit just before a merge into a branch.

I can't think of others. Add anything else you feel should be considered.

[iduhetonas]

This seems like a good place to look for a git development workflow.

[skeet70]

Yep yep! Another good thing to note is that when making a commit, you can reference Github issue number in it and it will close it with your commit message. eg: closes #6 anywhere in the commit will close the issue.

[iduhetonas]

Sweet, I've added it to the section up top.

[skeet70]

This is the one we've modeled off at work. It has many more pictures, which I'm always a fan of. As a side note, we almost went with Braintree payments for our marketplace :+1:

[iduhetonas]

I quite like their project flow!

The only disagreement I would have is that I don't like that all three of us working in the "develop" branch at once. I realize that Git is very good about merging; my only complaint would be that if we created a huge bug that wasn't apparent in the main branch by trying to fix another bug, or implement a feature, it'd be difficult to "reset" back to the point where that wasn't apparent. So rather than have a "hotfix" set on a tree, we would instead just have a list of separate branches that we use to work on bugs and issues.

Other than that, I like the style. In all, I'm extremely flexible on how we do this project, mostly because I'm not sure how any of our plans will work out between the three of us.

[skeet70]

...? We don't all work on develop at once. The pink on the left is features/bugfixes, a new branch for each one. You always do a pull before a push, so when you're merging back into develop, Hotfix was a branch where you do a where you basically do a commit that fixes an entire bug, which it would be pointless to make a branch for. It's extremely easy to rebase/reverse commits with this model, there's no ambiguity about where bugs are introduced or anything.

[iduhetonas]

I had a different idea of what features were from the diagram, and didn't think of them as bugfixes. Reading more thoroughly, and I like the way that they handle the "release" branches being "local only" bugfixes/features (of which I misspoke and was referring to, not the "develop" branch).

Another source of confusion is that I thought we had only used one branch for all bugs, rather than for our own, but this model addresses that.

I'd like to see this model placed somewhere else than in an issue, so once everyone understands how we'll be developing, I believe we should move that link to somewhere in the Wiki. Then we can close this bug.

How does that sound?

[skeet70]

Sounds good to me! Could make a development practices page and add stuff we sort on these to that.