Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)

How we use Git

(1/1)

The E:
Git is an amazing tool. However, it does work in a markedly different way than SVN does, and so different rules and recommendations apply when working with it. This post is intended to serve as a guideline for how the SCP and its members should use it, and which coders outside of the SCP can refer to in order to make their contributions integrate as seamlessly as possible.

Let's start with the basic premise. In git, forking and branching are cheap. This has a couple of implications. One is that it is entirely feasible to make a branch for every minor feature or bugfix, something that would be stupid to do in SVN. Therefore, we recommend that coders first start by forking the repository (Github makes this incredibly easy), then creating new branches under that fork while keeping the fork's master branch clean. These branches should follow a common naming scheme. A fix for a Mantis issue for example would be developed in a branch called "mantis/xxxx" where xxxx is the number of the mantis ticket; New features would be named "feature/new_and_cool_stuff".

Here's the Github guide on how to fork.

Once development is done, you can open a request for merge into the main fs2_open repository. Merge requests will then be reviewed by at least one other coder, who will then either give notes on how the patch can be made better, or merge it into the main master.

This process should be followed for pretty much everything. The only exceptions are Release and Release Candidate branches as well as major feature/refactoring branches (Which under svn would get their own Antipodes branch), these will be maintained in the main SCP repository. However, even for those branches, the commit-pull-request-review-merge cycle should be maintained.

Navigation

[0] Message Index