Code Change Process - UTACM/TexasACM.org GitHub Wiki

Making a Code Change

The master branch is the production branch. The server will automatically sync with the master branch and deploy whatever the master branch holds. To manage the frequency or other settings of auto syncing, sign in to HostGator’s cPanel and go to Cron Jobs. As of time of writing, the server runs cd ~/public_html && git reset –hard && git pull every quarter hour (:00, :15, :30, :45).

You should NOT develop on the master branch of the repository. Instead, fork a development branch, make changes, test it to ensure it works. The standard format for naming branches is <issue number>-<issue desciption>. For example, if issue #123 is to fix a scrolling issue, the branch should be named something like 123-scrolling.

Sync the master branch into your development branch regularly to reduce the chance of merge conflicts. Finally, submit a code review to the web administration team to merge your changes into master.

Conducting a Code Review

Code reviews help improve code hygiene and decrease the number of bugs that make it into the production stage. It also helps each team member understand the gist of what the other member accomplished. This way, all members will be familiar with code that they did not even write.

Once you have reached a good stopping point, sync your branch with master. Make sure you have tested your code on multiple platforms, which can be achieved using your browser's built in Developer Tools. Examine the file diffs one last time to code review yourself, then submit a pull request (or a code review) to the team. Always have the other team member review your code and/or commit before integrating the changes to master branch. Even content changes like images that have no code can have a negative impact on the viewing experience if images are too large and load slowly! You can respond to suggestions, start discussions, or mark a suggestion as completed on the GitHub website’s Pull Request page.

Look out for bad style, typos, or code that should be refactored. If there are issues, you can add comments to point them out, explaining what is wrong with the code, how it can be made better. Then send it back for revision. After the author of the code review has fixed the requested changes, and there are no more problems, only then should you approve the request and merge it into master. Don’t worry about being too picky. Point out any issues or suggestions, however small, so we can publish the highest quality of code.

Remember to drag the cards in Git issues to the correct status. Add comments to the issue to explain what you did if the task is somewhat complicated so that it can be referenced in the future. You can comment close # to close specific issues.