Skip to content

How to Github

Jump to bottom
MorMundHS-MA edited this page Aug 19, 2021 · 12 revisions

Git workflow

  1. Checkout to dev and pull latest changes

  2. Create feature branch from dev branch

  3. Write code, commit frequently, push changes to remote

  4. Create pull request

  5. Review pull request, request changes if necessary and implement requested changes

  6. Merge to dev

  7. Delete branch

Resources

If your new to git here are some good resources to get to know the basics:

Git basics: https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/

Git basics: https://www.youtube.com/watch?v=IHaTbJPdB-s](https://www.youtube.com/watch?v=IHaTbJPdB-s

Git workflow explained: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow Guide to pull requests: https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests

Pull request checklist

  • Is the code formatted correctly?
  • Unnecessary comments removed?
  • Printout statements removed?
  • If you made backend changes: Did all tests pass? Do you need to adjust some tests or write new ones?
  • If you made frontend changes: Did you test the UI on different devices/ browsers (Firefox, Chrome, Safari, different smartphone sizes)
  • Is your code easy to understand or do you need to insert some comments?
  • Explain the issue for the reviewer and your steps to solve the issue => makes it a lot more easy for the reviewer
  • Label your pull request (frontend/ backend/ testing/ styling/ sql/...)

pull request review

Resources:

How to do a review on GitHub: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request

Pull request review practice

  • Before starting a new ticket you have to look at the current opened pull requests and decide with the help of the labels (such as good first issue) what you can do (If later you feel like this is to complicated for you that's no problem you can always add a reviewer later)
  • Pick out an issue and assign yourself so that no two people work on the same ticket
  • Pull remote branch and test it local
  • Review line by line (best in the GitHub webpage) and add comments if necessary
  • If you have problems to understand the code there are 3 steps to get help
    • ask the author => add a comment to the line(s) you don't understand (maybe this is a sign that the code is written to complicated and there is a better way)
    • If you feel like you have bigger problems understanding the code and it's not just about specific lines, but more about the general logic, ask for a code walk-through with the author of the pull request
    • if you (and the author) are still unsure and don't want to merge yet you can ask for a second reviewer, ask for help on discord to address everyone
  • If everything looks fine and tests have passed/ requested changes have been made the reviewer merges the branch with dev
  • If you have questions/ problems that you want to assign for everybody ask on discord and add a link to the pull request, if you have small questions that the author can answer ask directly on GitHub to keep the conversation at one place

pull request review checklist

  • Do all tests work?
  • Do we need additional tests?
  • Is there double code?
  • All unnecessary comments removed? For example left printouts
  • Do the names make sense/ are intuitive, easy to understand?
  • Are there enough comments inline with the code?
  • Can anything be simplified?
  • test the feature local
  • test also different browsers (Firefox, Chrome, Safari, different smartphone sizes) for UI bugs

PS: If you have any suggestions/ ideas to make this process better/ additional resources, links just edit the file and add it directly or ask on discord.

Clone this wiki locally