Project Management

Adding your own content

To add your own code to the current project, follow these steps:

1. Create an issue

Create an issue specifying your fix / enhancement / feature. Make sure to properly add tags to the issue as every team has an associated tag.

2. Create a branch

Create your own branch off of the develop branch. You should name the branch based off of the issue you just created.

For example:

If your issue has an ID #56 and the issue is about fixing the menu, you should name the new branch 56-menu-fix

Every branch name should be preceded with its associated issue number.

3. Write your code

4. Rebase your code

While you were developing, there were most likely changes to the develop branch. DO NOT merge these changes into your branch, rebase them. This effectively merges the changes in without making ugly merges.

To do this, do the following (this is based on CLI commands, the CLI is prefaced with $):

# Get updated code
$ git checkout develop
$ git pull origin develop

# If the git pull failed, do the following command:
$ git reset --hard origin/develop
# This will overwrite your changes on the develop branch
# (you shouldn't be editing this branch anyways)

# Rebase your branch
$ git checkout [your-branch-name]
$ git rebase develop

# If there are conflicts, resolve them and then do the following:
$ git rebase --continue

Also please note that if you try to push to the repository it may fail. This is because you have rewritten history! You need to force push to your branch in order to update the branch history on GitHub. Do the following:

$ git push -f origin [your-branch-name]

5. Write more code

6. Rebase your "ready-to-be-reviewed" code

If you have made multiple commits to the same branch (after branching from develop), you should squash your commits into a single commit. Do the following steps to accomplish this:

# These steps are the same as the rebase step above
$ git checkout develop
$ git pull origin develop

# Rebase your branch
$ git checkout [your-branch-name]
$ git rebase -i develop

Running the git rebase -i command will display something like the following file in your default editor:

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Change all of the places, except for the very top commit, from pick to squash. Then save and quit the file to continue.

This will bring you to another editor to create the commit message you want to be displayed. It defaults to a combination of all your commits. Make sure to add Fixes #56 (your issue number, not 56) to the commit so GitHub will auto-close the issue. Save the file to finish rebasing.

See more at https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History.

7. Push your code

When you've finished rebasing (if needed) push your code to the repository. Use git push origin [your-branch-name] or if you have rebased git push -f origin [your-branch-name].

8. Make a pull request

Make a pull request for the code you just pushed. The base branch should be develop and the compare branch should be [your-branch-name]. Nothing will ever be merged into the master branch except for develop.

Please make sure to include the following things:

• Add reviewer(s) (all pull requests require it, even for admins)
• Assign the Pull Request to blackjack26
• Add appropriate labels
• Update title and comment to be logical for the pull request
• Make sure the issue is referenced in the comment

9. 🙏 Pray your code is beautiful

If a reviewer requires a fix, you must make the changes, repeat step #6 and #7 if necessary, and then wait for the code to be reviewed again.

Until the reviewer(s) accept the request, the code will not be merged into develop.