Difference between revisions of "Using Git and GitHub"

From Elcano Project Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
 
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.
 
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. 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 overwriting someone else's work.
+
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.
  
== Working with Git ==
+
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
 
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, fork elcano/Transceiver to Jane/Transceiver. Both of these repositories live in the cloud. 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.
+
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.
 
Suppose that on your PC you have updated the file xmit/RadioControl_rf69/RadioControl_rf69.ino.
Line 29: Line 31:
  
 
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.
 
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.
 
=== Settings.h ===
 
This file is required by most processors, but is not kept in any repository. It is meant to include individual vehicle features. All the rest of the code should be written to be portable across a wide variety of vehicles. Specific attributes of a trike (such as wheel diameter, turning radius, etc.) should be kept in a settings.h file for that vehicle. The file SettingsTemplate.h is kept in the General repository. This file should be used to set up an individual setting.h file.
 

Latest revision as of 01:37, 10 October 2019

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.