Git is an open-source, distributed code management and versioning system. Git does not force one particular workflow model on the team, allowing a lot of customization based on the needs of the project. For OctopodGames' Connect Four, below is a specific Git workflow that all developers MUST follow. NO EXCEPTIONS! (That means you, Ryley)

Every developer MUST have at least 3 branches in their repositories: master, release, and develop. However, devs are free to have as many additional branches in their private repos as they wish.

The master branch provides developers a safe, stable snapshot of the code. Developers cannot merge code into their master branch; it is to remain in sync with the latest stable release of the project. You'll thank me later when you screw something up and need to roll back your code!

All releases for the master branch must be tagged with their corresponding release version. All master branch tags will be annotated and signed using the Release Engineer's PGP Private Key. If you don't have a PGP Private Key or don't know how to create one, you shouldn't be the Release Engineer.

The release branch can be thought of as the "beta" branch. All code in this branch is feature-frozen, meaning no "net new" functionality will be added to this branch; only bug fixes will be committed. Developers should not commit to the release branch as it is also in the sole domain of the Release Engineer. We say "should not" because the release branch is, by definition, more volatile than the master branch.

All releases in the release branch will be annotated, but do not (and probably should not) be signed. Releases will follow standard Major.Minor.Patch-BuildNumber scheme. You can find more information about this scheme at semver.org.

The develop branch is where most of the fun happens. All of the current, actively developed code for the project is found in this branch. Code found in the develop branch is being actively worked on and can be thought of as completely unstable. Developers should not work directly in the develop branch, but that rule is not strongly enforced. Instead, devs should work in auxiliary branches, and merge their changes into develop when they're done.

Auxiliary branches are completely optional, but also completely recommended. A great way to think about auxiliary branches is for small features being actively developed upon. For example, if you're working on the Connect Four UI grid, you would make a "grid" branch, actively commit to it, and then merge it into the develop branch when you've finished the feature.

As stated above, it's recommended that you do most of your development in auxiliary branches, and merge them back into their parent branch when done. How do you do that? Easy!

git checkout <parent branch>
git merge --no-ff <auxiliary branch>

When doing a typical merge, git simply "fast forwards" the old ref to the new ref. With the --no-ff option, git actually creates a new commit on the parent branch. Why would you want this? When viewing the git tree in a visual browser (such as gitx or tig), you can see where the code branched off and was merged back in. It is REQUIRED to merge your code like this.

The lifeblood of any good project is good code. Along with good code, it is a good idea to leave a clean paper trail behind you, allowing others to track your progress and for you to revert back to past commits. Below are the rules for making good commit messages.

As a developer, it is up to you to decide when to make a commit. You can commit every line, every character, or every new feature; it is completely up to you (however, I beg you NOT to commit every line or character). Typically, a developer makes a commit whenever something new is added to the project. That "something" could be a new feature, a bug fix, or a logical stopping point in the code. Again, it is up to the dev's discretion when to commit, although it is recommended to commit as often as necessary (but no more often than that).

When the developer commits their code, they are required to leave a commit message. Commit messages should be designed like an email: the first line being the subject, all remaining lines going into detail about what changed.

For example, say you are working on Connect Four and you created the play grid. A logical commit message detailing that could look something like this:

Created the Grid

The grid itself is nothing more than a series of <div> tags,
with an outer "row" <div> encompassing inner "column" <div>.

As explained above, when you merge your code from an auxiliary branch into its parent branch, git will create a new commit. The default commit message should not be altered, as the Release Engineer can simply look through the log to see what the developer did.