Using Git and GitHub

Why we use Git and GitHub

Git is a distributed version control system. It allows safely making changes, with the ability to roll back to a previous version if a change doesn't work. It simplifies having multiple people working on the same files.

GitHub is one of several online code sharing sites that support use of Git. GitHub adds some collaboration features on top of Git, such as elaborate code review tools, notification of changes. The main collaboration feature, though, is allowing one user to have their own copy of someone else's repository, and easily contribute changes back to the original.

We use the "fork / pull" model of software development. In this model, each software project has a main repository. Contributors to the project make their own copies (forks) of the repository on GitHub, then "clone" their own GitHub repository onto whatever machine they will use for development. GitHub is mainly used for storage and sharing -- actual code changes will typically be done on one's own machine. After making changes, the developer makes a "commit" -- an update to their local repository, and "pushes" that commit to their own repository on GitHub. They then do a "pull request" -- this asks the maintainer of the main repository to review their code, and accept (pull) it into the main repository. This process allows people to propose changes independently of other developers -- there is no issue with two people trying to insert changes into the main repository at the same time, and one overwriting the other's work.

If another developer has had their changes accepted into the main repository in the meantime, then the next developer to make a pull request may need to bring in the other developer's work, to make sure their own changes are compatible. We'll describe this process in some detail below, as it is the most tricky part of working with Git.

Overview of working with Git

See the tutorial: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners

Typically, you will start with an Elcano repository, and then fork it to your own repository on GitHub. For instance, GitHub user Jane would fork elcano/Transceiver to Jane/Transceiver. You would then download ("clone") Jane/Transceiver to your PC. You can do a lot of work in that repository on your PC. When you have code on your PC that has been tested and is ready to share with others, the next step is to upload it.

Suppose that on your PC you have updated the file xmit/RadioControl_rf69/RadioControl_rf69.ino. You need to get into a bash shell window on your PC, and use cd to make Jane/Transceiver the current directory.

git status // should show nothing changed

git add xmit/RadioControl_rf69/RadioControl_rf69.ino

git commit -m "Removed a delay statement that blocked while waiting for an ack"

Be sure to make your messages reflect what you did for this particular fix. Git supports small incremental changes, and make it possible to roll then back if needed. Please do not wait until the end of the quarter to dump all your changes into the main repository.

git push origin master

This command assumes that you have set origin to the URL for xmit and master to the URL for Jane/Transceiver. It puts your new code into your repository on the cloud.

The next stage is to make a pull request. You are asking to have your code made part of the official Elcano/Transceiver. You are not allowed to directly push to Elcano repositories. If your pull request is accepted, your code becomes part of the Elcano project. A pull request is made from a web browser on Elcano/Transceiver, or whatever repository you are working with.