Skip to content

Latest commit

 

History

History
128 lines (83 loc) · 5.01 KB

README.md

File metadata and controls

128 lines (83 loc) · 5.01 KB
Raw

Build

 

This is the official repository of HYPED. HYPED is a student society at the University of Edinburgh dedicated to accelerating the development of Hyperloop and implementing the technology in the UK. HYPED is advancing both technical and commercial development of Hyperloop, having seen success in two international competitions. https://hyp-ed.com/

Contributing

The following is a set of guidelines for contributing to HYPED. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Coding Style

Since we will have dozens of developers coding for the pod, it is very important that everyone adheres to the same code style. For that purpose we have created the following style guide.

Git

Git is a prerequisite for this project. If you have not attended any git workshop yet or are not permitted to code, please ask Brano for further instructions.

Workflow

For our project we are using the Gitflow workflow. Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.

Rules

  • Always use git status.

  • Perform work in a feature branch. Why:

    Because this way all work is done in isolation on a dedicated branch rather than the main branch. It allows you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. Read more...

  • Always use git pull --rebase while working in a feature branch.

    Why:

    Because git pull (without --rebase) would create merge commits which only clutter up the history without providing any useful information.

  • Branch out from develop.

    Why:

    This way, you can make sure that code in master will almost always build without problems.

  • Never push into develop or master branch. Make a pull request.

    Why:

    It notifies team members that they have completed a feature. It also enables and enforces easy code reviews.

  • Delete local and remote feature branches after merging.

    Why:

    It will clutter up your list of branches with dead branches. It insures you only ever merge the branch back into (master or develop) once. Feature branches should only exist while the work is still in progress.

  • Before making a pull request, make sure your feature branch builds successfully and passes all tests (including code style checks).

  • Write good commit messages. Write in imperative mood style and capitalise the messages.

    You are welcome to use git commit without the -m "<message>" flag. This will bring up a text editor (likely nano or vim so make sure you know how to use those first). You can write your short commit message on the first line and then a longer description on the next line. The longer description should explain why you did what you did and should be phrased as if it was an email. Don't use this for small and obvious commits.

Do NOT

  • Force push (git push -f)
  • Squash branches

Everyday workflow

  • Checkout a feature branch.

    git checkout <subteam-feature>

  • Make changes.

    git add
git commit -m "commit"

  • Sync with remote to get changes you have missed.

    git pull --rebase

  • If you have conflicts resolve them and continue rebase. (Remember not to commit.)

    git add <file1> <file2> ...
git rebase --continue

  • Push your branch.

    git push origin <subteam-feature>

Start a new feature

  • Start a new feature branch. The prefix of the branch should be the standard abbreviation of your subteam.

    git checkout develop
git checkout -b <subteam-feature>
git push -u origin <subteam-feature>

    Standard abbreviations

    mgt - Management (Heads)
    stm - State Machine
    nav - Navigation
    cmn - Communications
    lib - Libraries
    mot - Motor Control

Submit completed feature

  • Make a pull request and resolve conflicts.

  • Pull requests will be accepted, merged and closed by a reviewer.

  • Remove your local feature branch if you are done.

    git branch -d <subteam-feature>