Converted documentation folder into wiki submodule

.gitmodules

@@ -2,3 +2,6 @@
 	path = groundStation/src/vrpn
 	url = https://github.com/vrpn/vrpn
 	ignore = dirty
+[submodule "wiki"]
+	path = wiki
+	url = git@git.ece.iastate.edu:danc/MicroCART.wiki.git

documentation/Multi-platform Integration.md

-# Multi-platform Integration
-
-## Table of Contents
-*   Brief
-*   How to connect another vehicle
- *   Make / Flash a physical network interface
- *   Integrate the network interface onto the control system for the vehicle
- *   Configure VRPN and Backend
- *   Setup GCS Host AP configuration
- *   Controlling Multiple Vehicles using CLI
- 
-## Brief
-This markdown file will walkthrough the necesary system configuration needed to be done to control multiple vehicles with the GCS and VRPN system. This 
-description will link to other relevant documentation files located in the MicroCART repository. The 2019-2020 MicroCART team's project is used as an example of how 
-to go through this process. The GCS can control multiple vehicles at once, but using this feature is not recomended. The control software lags considerably 
-when using multiple vehicles. The VRPN updates are slower for multiple vehicles, so when you are controlling multiple vehicles you should be sure to have a 
-failsafe for the vehicles like an RC kill switch.
-
-## How to connect another vehicle
-
-### Make / Flash a physical network
-The GCS has a wifi app software folder that holds stopAP and startAP scripts.[AP Scripts Software] (https://git.ece.iastate.edu/danc/MicroCART/tree/master/groundStation/wifiap "AP Scripts Software")
-These scripts can be ran to make the GCS act like a host wifi network like a router. Don't do that just yet, because what good is a wifi hotspot if nothing 
-is connecting to it. The GCS communicates to client devices with TCP packets. You need something like a network interface to connect to the wifi network and
-route the control packets from the GCS to the vehicles controls. That sounds like a lot of work, but the MicroCART repo already has support software for one 
-type of adapter. The ESP8266 chip was used as the network adapter/wireless interface for the 2018-20202 MicroCART drones. It has a UART interface, so linking it to whatever
-controls the vehicle shouldn't be a huge issue. If the GCS is the AP(acess point), then you should flash the ESP8266 with client firmware. There are tons of docs on flashing
-these wifi chips that can be found [Here] (https://git.ece.iastate.edu/danc/MicroCART/tree/wifi_flash/wifi_bridge "here"). 
-After you have these flashed you will want to connect them to your vehicle's control system.
-
-### Integrate the network interface onto the control system for the vehicle
-This part is dependent on what you are trying to control. Our drone used a breakout board that had a port designed to match
-the pins on the wifi chips. Here is a picture below.
-
-### Configure VRPN and Backend
-This part is optional. It isn't necesary to send VRPN data if you are using something like GPS, but 
-we used vrpn, so I will list the macros that need to be set in the backend.
-First, add a new trackable to the vrpn system. if you are going to use VRPN calibrate it first.
-[Docs for callibration] (https://git.ece.iastate.edu/danc/MicroCART/blob/master/documentation/how_to_calibrate_the_camera_system.md "Docs for Callibration")
-After callibrating, you want to track something, so use one of the black plastic ir beacon holdlers in the camera stuff box. This black plastic
-thing will be tracked by the camera system. If you have an optitrack project open you should see a number of small dots on the screen matching the number of
-IR beacons you put on the holder. Left click and drag your mouse over your selection, release, then right click one of the dots and select trackables->Create trackable tab.
-You should see something on your screen similair to what's shown below.
-
-VRPN should now be streaming to the GCS, but you need to set options in the GCS to recieve it.
-To recieve VRPN data and forward to a vehicle you need to create a trackable object for that in the config.c file.
-[config.c] (https://git.ece.iastate.edu/danc/MicroCART/blob/master/groundStation/src/backend/config.c "config.c")
-You should just be able to copy a trackable object from config.c and change the QUAD_SERVER_NAME and QUAD_IP, QUAD_PORT macros to match
-your network interface (discussed in setup GCS Host AP config) and trackable name. Change the prefix before @ on the QUAD_SERVER macro to match the trackable's
-name on optitrack. After you make a new trackable, also change the NUM_TRACKABLES macro in the GCS to reflect the new number of trackables.
-
-### Setup GCS Host AP Config
-Use the startAP script to create a wifi hotspot (READ the docs before using startAP!) [wifi_app_docs] (https://git.ece.iastate.edu/danc/MicroCART/blob/master/groundStation/wifiap/README.md "wifi_app_docs"),
-then connect to it with your network interface on your vehicle. 
-Everything else should be all setup, now you just need to change the QUAD_IP and QUAD_PORT numbers in config.c. 
-You can find the values for these by using a network analyzer like wireshark. To run wireshark, install it onto your machine, add its executable to the path,
-and type sudo wireshark in terminal. You should see a wlp2s0 interface under start options. Click on this then start capture. 
-After starting capture, turn on your vehicle. If your vehicle connected you should see an IP address pop up like shown below.
-set the QUAD_IP to this ip in config.c. Also set the QUAD_PORT to the TCP_PORT field in user_config.h in the esp2866 client firmware.
-After all these are set run make to recompile the backend restart your vehicle and run ./backend. The backend should say it connected successfully.
-
-
-### Controlling Multiple Vehicles using CLI
-If the backend said something about connecting to your client platforms, then you can test its connection.
-You can select which platform you want to talk with by opening up another terminal while backend is running and using
-./settrackable trackable_name
-You can get the name of the current trackable using
-./gettrackable 
-Besides those commands, everything should work the same as controlling one vehicle. Try using getnodes or getparam to really make sure communication is successful.
-
-

documentation/ci_faq.md

-# Continuous Integration (CI) FAQ
-
-## Why did my commit fail CI?
-On every commit, a script runs that performs a number of things, including
-compiling code and running unit and functional tests. Whatever you did
-apparently broke one of these things.
-
-## Why should I care about the CI results?
-CI _immensely_ streamlines the development cycle by helping us catch bugs
-immediately, allowing us to fix them early before they plague us (or future
-users of the code base). It's a common industry practice. If you break the CI 
-pipeline, don't ignore it! Try your best to get the branch back in working
-condition.
-
-## Okay, so my commit failed CI, and I guess I care. What should I do?
-1. Re-run the build. 
-   - Sometimes something weird happens, so it's good to check this.
-2. Figure out what you did wrong and fix it. 
-   - If you click on the build, you should be able to see the exact logs of the
-     build process. Debug the error to figure out what went wrong. Maybe you 
-     failed a test. You may need to open the source code for the test to see
-     where you failed, which is very insightful into figuring out what went
-     wrong.
-3. Figure out what CI is doing wrong.
-   - Sometimes a test might be poorly designed. At this point, it can be really
-     tempting to just ignore the build failure altogether (don't do that!), or
-     just remove the broken test (not as bad, but still don't do that). The best
-     thing is to fix the test so that we continue to have good regression
-     test coverage over our code.
-
-## My build failed due to unavailable software. How do I install things on CI?
-Each build is run within a docker image. Add whatever software you need on the
-`sudo apt install ...` line inside of the `.gitlab-ci.yml` file in the root
-directory.
-
-## How does CI work?
-When a commit is added to a branch in our repository, a notification is sent out
-to our gitlab-ci-runner, which instructs it to checkout the updated branch and
-run the directive in [`.gitlab-ci.yml`](.gitlab-ci.yml). It then runs each directive, which is
-made up of bash scripts to execute. In our case, we run two scripts, 
-[`ci-build.sh`](ci/ci-build.sh) and [`ci-test.sh`](ci/ci-test.sh), 
-which compile projects and run checks, respectively. Look at these scripts to 
-learn more about how they work. If some error occurs during the script 
-(perhaps a forced error generated by a failed test), then the runner sends a 
-message back to Gitlab indicating that the CI failed. Otherwise, it succeeds.

documentation/how_to_calibrate_the_camera_system.md

-# How to calibration the camera system
-
-On the computer Coover 3050-07, open the Tracking Tools program. Make sure you have all the tools required which include a 
-wand and ground plane component. These are usually kept on top of the cabinets in the corner of Coover 3050. In addition to 
-these instructions see the [DANC wiki page](https://wikis.ece.iastate.edu/distributed-autonomous-and-networked-control-lab/index.php/Distributed_Autonomous_and_Networked_Control_Lab_Wiki)
-which may have more information as well as the [OptiTrack Wiki](https://v20.wiki.optitrack.com/index.php?title=Calibration).
-
-All steps take place on the OptiTrack - Tracking Tools software on the Coover 3050 computer co3050-07.
-
-Below shows the OptiTrack - Tracking Tools Software on initial opening, many of the steps will refer to actions that can be seen
-on this image.
-
-![alt text](./images/OptiTrack_Tracking_Tools.PNG "OptiTrack - Tracking Tools")
-
-1. Open up a new project with "New Project" button, directly under File drop down menu. Or navigate to "File->New".
-2. If the "3-Marker Calibration" window is shown on the screen, usually on the right side, continue to next step. 
-   If not go to "Tools->3-Marker Calibration".
-3. Now that the 3-Marker Calibration tool is open make sure to remove as much of the IR disturbance as possible, 
-   more disturbance leads to worse calibration. Usually you need to ensure all window blinds are down and that 
-   all IR reflective components (like the Quad) are out of the camera system view.
-4. After as much of the IR reflective components are removed from view click "Block Visible" in the "3-Marker Calibration" 
-   window to remove the left over spots.
-5. Before you start wanding check that the following configuration options are set.
-    * Quality -> Very High
-    * OptiWand -> Large (500mm)
-	
-6. Click "Start Wanding", directly next to the "Block Visible" button in the "3-Marker Calibration" window.
-7. This step will take awhile (approx. 10 minutes) as you wand the entire area of the camera system. Make sure to get at least 5000 samples
-   for each of the cameras. Try not to exceed 10,000 samples as this can lead to worse calibration results. Walk around the camera area moving
-   the wand in a variety of different movements to try to cover the full camera volume.
-8. After sufficient samples have been taken click "Calculate" within "Calibration Engine" and wait until all cameras have exceptional
-   listed next to them before continuing. This process takes 5-6 minutes on average.
-9. Click "Apply Results" then "Apply" when the next windows comes up. It will prompt you to save a timeline, just click "Save".
-10. The next step is to set the ground plane. This window should be automatically switched to after you save, but if not you can switch at the 
-    top of the window within the "3-Marker Calibration" window by clicking "Ground Plane".
-11. Set up the ground plane component as shown in the window above. The Z direction should point towards the ceiling, X direction towards the 
-    white boards, and the IR balls should be facing towards the door. If you lift up the carpet tiles you can use the lines on the floor to
-	orient the piece in the correct X direction. Additionally, the levels in the lab may help with this process to get the best results.
-	
-	![alt text](./images/CameraGroundPlane.jpg "Camera Ground Plane")
-
-12. Once everything is set, check that the "Vertical Offset (mm)" is set to 55, this value can be measured with a meter stick and it
-    is the distance from the ground to the height of the lower IR ball. Next, click "Set Ground Plane". This will prompt you to save a 
-	file, just click "Save".
-13. Save the project, with the "Save Project" button or go to "File->Save Project".
-14. The last step is to enable streaming to VRPN. If you test the backend within the ground station directory without the following steps
-    to complete it will not connect to the VRPN system.
-15. The OptiTrack Tracking Tool software support streaming to VRPN go to "View->Streaming Pane".
-16. In the "Streaming Properties" windows enable "Broadcast Frame Data" within "VRPN Streaming Engine" and ensure that the 
-    "VRPN Broadcast Port" is 3883.
-17. Save the project, and you are now done!
\ No newline at end of file

documentation/how_to_charge_lipo.md

-# How to charge the LiPo batteries
-
-This tutorial includes instructions to safely charge the Li-Po battery. The quadcopter uses a 3S Li-Po battery with 11.1V nominal voltage.
-
-1. Start by turning on the charging station’s power supply, which should be on the left side of the charging station. The power supply should be at 17 volts.
-  ![image](/uploads/fa01915053a07486dfce28ba4f7c32f5/image.png)
-2. On the charging station:
-  - Connect the balancer (connector with many white slots) and the charging cable (yellow connector)  to the charging station.
-  ![image](/uploads/0e19f7845a49d6fac19e7d728f0a69af/image.png)
-  - Cycle through (Hit “Enter” and use “Up” and “down” to cycle) the memory banks until you find the correct setting for the battery you are using. The one in this demonstration is a LiPo with nominal voltage of 11.1V and a capacity of 2200 mah. The correct settings for this battery is located under memory no. 6. 
-3. Connect the battery to the balancer and charging cable. Plug the balancer into the slot corresponding the number of cells the battery has. In this case the battery is 3 cells so you would plug it into the 3S balancer slot.
-  ![image](/uploads/d1db7c34b5c4433b575b30709711b943/image.png)
-4. Hold “Enter” on the charging station until it prompts you for “Charge Start Solo Mode”. Hold “Enter” again to check and confirm the battery’s voltage and cell count.
-  ![image](/uploads/4314a5d12fd63b007489a232ee482ce6/image.png)
-  ![image](/uploads/bc8ea0722ed7b1de6b105ea8503b0675/image.png)
-5. Press “Enter” to start the charging process.
-  ![image](/uploads/f1a0c5f9cf659df573893d4954422014/image.png)
-6. When the battery is done charging the charging station will make a continuous ringing sound. The screen on the charging station will say “LiPo End/CHG”. Hold “Enter” to return to the main menu. Unplug the battery from the charging cable and the balancer. Power off the charging station’s power supply.
-  ![image](/uploads/930b76e122fa1507a62ad84cc72fa4c1/image.png)
-
-

documentation/how_to_demo.md

-# How to demo the quadcopter
-
-Follow this How-To to get the quadcopter up and running in Coover 3050. 
-
-**Table of Contents**
-
-[[_TOC_]]
-
-## Setup Infrared Camera System
-
-1. To start up the camera system, log into the camera system computer (co3050-07) with the following username and password:
-
-    username: `camera` <br />
-    password: `Camera`
-
-2. Once the OS is done loading, start up the program "Tracking Tools from the desktop".
-3. From the startup window, choose "Open existing project"
-4. From `D:\TrackingToolsData\FromLaptop` choose "TrackingToolsProject 2018-XX-XX X.XXpm", where the X's are the most recent project, in the "Optitrack_Configuration" folder
-6. Then go to File -> Open and choose "Microcart.tra" in the same folder
-  - This should create a "UAV" under "Trackables" in the Project Explorer on the left side of the screen
-7. Now you should be able to move the quadcopter trackable around in the tracking area, and see it update in real-time on the screen.
-
-## Setup Ground Station
-On the ground station computer (Co3050-microcart), log in with the following credentials. 
-
-username: `ucart`<br>
-password: `microcart`
-
-Navigate to the ground station folder in a Terminal. 
-```bash
-$ cdsenior
-BackEnd  Cli  logs  Makefile  obj  README.md  src  ucart.socket (or something like that)
-```
-
-If this is the first time using the ground station after cloning, you need to make VRPN.
-From the `groundStation` folder:
-```bash
-make vrpn
-```
-
-To make the actual ground station program, e.g. if there have been any changes, run `make` from the `groundStation` folder.
-
-## Setup Backend
-Navigate to the backend directory, from the ground station folder.
-```bash
-$ cd src/backend
-```
-
-Check that in config.h [`NUM_TRACKABLES`](../groundStation/src/backend/config.h#L128) is set correctly, usually 1.
-
-Check that in config.c the [`trackables`](../groundStation/src/backend/config.c#L16) array is setup correctly. By default the quad is first element in the array.
-
-## Setup Transmitter
-The RC transmitter is used to manually control the quad.
-1. Ensure the transmitter has the following state before turning it on (Note these are marked on the controller):
-  - "Gear" is set to 0
-  - "Flap" is set to 1
-  - Throttle is set to the lowest position
-2. Turn on the transmitter.
-
-## Copy Boot Image
-To obtain an SD card image, navigate to the desired tag in GitLab (`team_17-16_demo`) and download the desired boot image. Copy it to an SD card, and rename it to `BOOT.bin`, which is the default filename for the Zybo to boot from.
-
-## Setup Quadcopter
-First, insert a fully charged battery with a monitor connected. The best policy is to always keep a battery monitor plugged in to prevent the battery from discharging too far.
-
-
-1. Make sure the connection to the motors (red Deans connector) from the main power line is **disconnected**.
-2. Insert the Li-Po battery into the holder beneath the quad, and plug it into the quad. See the image below to know how far back to place it.
-![battery_placement](images/battery_placement.jpg)
-3. Tether the quadcopter down so it cannot hit the ceiling or valuable people.
-4. Turn on the Zybo Board using the switch.
-    1. The "PGOOD" Light should turn red.
-    2. After the program has been completely loaded, the green DONE LED should turn on.
-    3. **NOTE: The I<sup>2</sup>C devices do not get turned off when the Zybo switch is turned off, so to reboot, it is necessary to completely disconnect the battery, in addition to turning off the Zybo board switch.**
-  ![image](/uploads/3aa1363e9f75982f259c2631bf9bcb8f/image.png)
-5. Ensure the quad and transmitter have connected successfully.
-    * The RC transmitter should have GAUI 330X selected and displayed on the screen. With the quad and transmitter on, the unit on the quad labeled Spektrum AR610 should have a blinking orange light or solid orange light (We don't know the difference, but the both seem to work?). If this is not blinking or solid, try restarting the quad and transmitter with the transmitter closer to the quad. 
-  ![image](/uploads/f08672919265c5ff0017d28c1ba97770/image.png)
-  ![image](/uploads/1a10172835c079f41395638d871f98e1/image.png)
-
-6. Plug connect the motors to the main power line.
-
-## Connect to Quad WiFi
-The quadcopter creates its own access point, called "MicroCART", with password "m1cr0cart". Be sure to be connected to this before trying to connect to the quadcopter.
-
-## Start the Ground Station (GUI)
-Execute the following on the ground station from the root of the `groundStation` folder.
-
-In one terminal, run the backend:
-```bash
-./GroundStation
-```
-
-Then hit "Start"
-At the top of the log window, you should see:
-```Connectiong to Quad @ 192.168.1.1:8080
-connection successful!```
-
-To verify that the quadcopter software is running and responding to packets, go to the "Controller Graph" tab and hit "Refresh Controller Graph". The current graph will show up.
-
-## Flight
-1. Using the transmitter, flip the "Gear" switch to 1.
-  1. You should see the green LED4 MIO7 turn on. If the light does not turn on, then check these these things:
-      * The Throttle is low
-      * The flap is set to 1
-      * The proper start-up sequence was not followed. Power down everything and unplug the battery, and start booting over.
-2. Continue following steps in either the Manual Mode or Autonomous Mode
-
-### Autonomous Mode
-1. Find somebody else to be running the transmitter, so they can take control in case bad things happen:
-   * Scenario 1: Quad is being silly, and it needs to take a time out. Switch Flap back to 1, and fly/land it in manual mode.
-   * Scenario 2: Quad is actively attacking itself or others. Cut off all motors by turning the Gear switch to 0.
-2. Turn the Flap switch to 0 to turn the quadcopter into autonomous mode.
-3. From the upper-left corner, click "Scripts", and from the drop-down menu, run the `take_off.sh` script.
-4. Waypoints can be set from the "Navigation" tab, waypoint files can be loaded, etc. See the Ground Station GUI README to find out more.
-5. Land the quadcopter by running the`touch_down.sh` script from the Scripts drop-down.
-
-### Manual Mode
-2. Start flying the quad. Below is a summary of how the manual controls work.
-  ![image](/uploads/b9e51151c344cba8f42f6b1d21273f31/image.png)
-
-

documentation/how_to_document_things_on_gitlab.md

-# Documentation on Gitlab
-We can use Gitlab to host our documentation by exploiting the fact that Gitlab
-automatically renders Markdown (.md) files as HTML in the browser, making it
-easy to read and show images.
-
-# Organization
-We will be using the top-level `README.md` as our main page for documentation.
-You might notice that this page is automatically rendered on our [main Gitlab
-project page](/../).
-
-Ideally, all documentation should be reachable from links on this main page.
-For documentation that is whole-project encompassing, those links should go
-on the main page itself. For documentation that is sub-topic specific (quad,
-ground station, controls), add an appropriate link on the sub topic's README.md
-page. See the Quad section for an example.
-
-Ideally, all Markdown (.md) files should go inside some `doc` or `documentation`
-folder (with exception to the READMEs).
-
-# Editing
-If you are familiar with Markdown and Git, you can just edit the documentation
-from within your normal Git workflow.
-
-However, Gitlab also makes is relatively easy to edit Markdown pages for
-documentation right in the browser. To edit a Markdown page, select "Edit" at
-the top right. This will bring up an editor that you can use to make changes.
-To preview the final project, use the "Preview" tab at the top left. To achieve
-desired formatting, you will need to use the Markdown syntax - see the [Gitlab
-Markdown reference](https://docs.gitlab.com/ee/user/markdown.html).
-
-To create a new file within Gitlab, go to the "Repository" tab and then "Files"
-tab. As you navigate through our files, you will see a "+" (plus sign) button.
-From here, you can create a new Markdown file, upload a new file, or create a
-folder (say if you need to create some `doc` folder).

documentation/how_to_use_git.md

-# How to use Git
-This project uses Git. That means that if you plan to make any edits to the
-project, you'll be using some Git command.
-
-## Where is everything?
-Everything is on the master branch. In git, a _branch_ is like a timeline of
-the project. The timeline is composed of incremental changes, called _commits_.
-In the case of the master branch, these commits go all the way back to the
-beginning of the project. Nobody can delete history on the master branch. Once a
-commit is added, it is permanent. When you browse files on Gitlab, you are
-likely looking at the most recent state of the master branch.
-
-## How do I make changes?
-To make a change to the project, you'll need to make a commit to the master
-branch. You can technically make edits to files right in Gitlab, but most
-people prefer to copy the entire Git project locally to their PC, make
-edits, and then copy those changes back to the main Git project on Gitlab.
-
-### Using your own computer to make changes
-#### Setup (Only need to do once)
-First, [setup an SSH key](https://git.ece.iastate.edu/help/ssh/README).
-
-Clone the project:
-```
-git clone git@git.ece.iastate.edu:danc/MicroCART.git
-```
-That was easy. You can enter the directory you just made, and see all of the
-project files.
-
-#### Actually making changes
-First, sync to be sure your personal computer has the most recent state of
-master on Gitlab.
-```
-git pull origin master
-```
-Now you can make your edits. Do whatever you like to the project.
-
-When you are finished, look over the changes you have made.
-```
-git status
-git diff
-```
-If you are happy with you changes, it is time to prepare a commit.
-
-Stage each changed file in order to commit them:
-```
-git add (name your files here)
-```
-If you don't want list out every file you changed, you can do clever things
-like using the entire folder where the changed files are (sometimes people will
-use `.` for the current directory).
-
-Look at the files you have staged:
-```
-git status
-```
-
-If all looks well, it is time to commit:
-```
-git commit -m "describe your changes here"
-```
-If you'd prefer to use a text editor to write your commit message, drop the `-m`
-part.
-
-You can look at the commit you just made:
-```
-git log -n 3
-```
-
-Now we need to sync your master branch with the master branch on Gitlab.
-```
-git push origin master
-```
-
-It's likely someone else has made a change since your last sync, so you may get
-an error saying your master is out of date. In that case, sync your master with 
-Gitlab's master again.
-
-```
-git pull origin master
-```
-
-If you happend to be editing the same lines as someone else, you'll get the
-so-called "merge conflicts." In that case, look at the error output to determine
-which files have conflicts, and go edit those files. You'll have to choose which
-changes to keep. At the end of the day, you need to get rid of the `<<<` lines.
-Once you have fixed everything, `git add` those changes and `git commit` to
-create a merge commit. Maybe do another `git log` after everything to be sure
-everything makes sense.
-
-In the event that the conflicts are too confusing and you want to abort or
-start over.
-```
-git merge --abort
-```
-
-Once you have synced your master with Gitlab's master again, sync Gitlab's
-master with your master again:
-```
-git push origin master
-```
-
-If all succeeds, you should be able to see your commit on Gitlab.
-
-#### $%!@? I have to remember all of that?
-That was the exhaustive list to cover all of the worst case scenarios. Typically
-things go much smoother:
-```
-git pull origin master                 # get most recent stuff from Gitlab
-# make some changes
-git add .                              # stage files to be committed
-git commit -m "change something"       # commit the staged files
-# make some more changes
-git add .                              # stage files to be committed
-git commit -m "change something else"  # commit the staged files
-git pull origin master                 # pre-emptively merge Gitlab's master into mine
-git push origin master                 # sync my 2 commits to Gitlab's master
-```
-It really isn't that bad once you use it for a week. Just don't panic when you
-get your first merge conflicts 😉
-
-## Other workflows
-What we just described is the bare minimum Git workflow. Most people don't like
-working this way. We encourage you to research other workflows, like a Git
-branching workflow.
-
-## Branching Workflow
-The idea behind a branching workflow is that you would have a safe, isolated
-environment to make your changes that no one else will disturb. It also prepares
-your changes for a merge request in the future that can be reviewed by the team
-before merging to master.
-
-To begin, confirm that you have no changes in progress and that you are on the
-master branch.
-
-```
-git status
-git branch
-```
-
-The status command should indicate nothing. If you do have changes, commit them,
-stash them, or discard them.
-
-The branch commdn should indicate that you are on the master branch. If not
-switch to it now.
-
-```
-git checkout master
-```
-
-Now let's be sure we are starting with the most recent version of master.
-```
-git pull origin master
-```
-
-At this point, we are ready to begin. 
-
-Create a branch for yourself, ideally named according to fix or feature that
-this branch is supposed to implement.
-
-```
-git checkout -b name-of-my-branch
-```
-
-Notice that your branch has changed:
-
-```
-git branch
-```
-
-Now you can make edits and commits as you normally would.
-
-It's good practice to update the remote repository with a copy of your branch.
-You should periodically push it once you have made some commits, and definitely
-once you are finished with the fix or feature associated with this branch.
-```
-git push origin name-of-my-branch
-```
-
-At this point, the branch should be on Gitlab, and you can open a merge request
-to have this branch merged into master. You can safely keep committing to this
-branch and pushing it to the remote after making a merge request, and the most
-recent changes will be automatically updated to the merge request.
-
-Occasionally, your merge request might be ineligible to merge if there would be
-merge conflicts. In that case, you'll have to resolve the merge conflicts
-locally before the merge request can be accepted.
-
-While on your branch (and when there are no current changes)
-```
-git pull origin master
-```
-
-This will merge the remote master into your branch. If there are merge conflicts
-you'll resolve them at this time. When finished, push the changes again to the
-remote, and the merge request should be eligible for acceptance.
-
-```
-git push origin name-of-my-branch
-```
-
-Once your merge request has been accepeted on Gitlab, you can simply delete this
-branch locally. (You'll need to be on the master branch to do that.)
-
-```
-git branch -d name-of-my-branch
-```
-