Git Workflow

Ignoring files (general)

Please add operating system specific hidden files, editor specific swap files, and other things you need to ignore to your global git ignore. See ignoring files for details.

Closing issues with commits

Your commit message should reference the corresponding issue with closes #11 or fixes #12 so the corresponding issue will be closed and the issue will contain a link to the commit. More information on closing issues with pull requests.

General Guidelines

• Always work from a fork.
• Always cut new feature branches from master (you'll be issuing pull requests from them)
• Always use pull requests to merge changes (via github.com).

Updating your Branches

• Hotfixes may be directly branched from master; otherwise, all commits should be made from feature branches off the master branch
• Use git pull --rebase to refresh from upstream branches. This keeps your Git log free of merge commits.
  • You can set this to be Git's default behavior by running git config --global branch.autosetuprebase always

Workflow Diagram

Pull Requests - Futuristic Code Review

Pull Requests are living discussions that streamline the process of discussing, reviewing, and managing changes to code.

There's only one way to get that sweet, sweet code of yours into the upstream satellite-games/Satellite, and that's through a github.com pull request from your personal fork. We don't use command line merges (at least not to do this).

GitHub Pull Request = Code + Code Comments

Rebase Team Policy:

When a feature branch’s development is complete, rebase/squash all the work down to the minimum number of meaningful commits and avoid creating a merge commit –while the work is still in progress and a feature branch needs to be brought up to date with the upstream target branch, use rebase – as opposed to pull or merge. This allows us to prevent pollution of the history with spurious merges.

Pros of Rebase:

Code history remains flat and readable. Clean, clear commit messages are as much part of the documentation of your code base as code comments, comments on your issue tracker etc. For this reason, it’s important not to pollute history with 31 single-line commits that partially cancel each other out for a single feature or bug fix. Going back through history to figure out when a bug or feature was introduced, and why it was done, is going to be tough in a situation like this. Manipulating a single commit is easy (e.g. reverting them).

NOTE: When history is rewritten in a shared branch touched by multiple developers breakage happens.

Cons of Merge

History can become intensely polluted by lots of merge commits, and visual charts of your repository can have rainbow branch lines that don’t add too much information, if not outright obfuscate what’s happening. merge-1

Also, debugging using git bisect can become much harder due to the merge commits.

Credits

Adapted from Git Flow and GitHub Flow.