Using Git and GitHub - Revision history

Ptressel at 01:37, 10 October 2019

2019-10-10T01:37:23Z

Ptressel: /* Why we use Git and GitHub */

2019-10-10T01:21:54Z

‎Why we use Git and GitHub

Ptressel at 01:21, 10 October 2019

2019-10-10T01:21:04Z

Ptressel: Ptressel moved page GitUsage to Using Git and GitHub: The abbreviated name was showing up as the page title.

2019-10-10T00:51:59Z

Ptressel moved page GitUsage to Using Git and GitHub: The abbreviated name was showing up as the page title.

Ptressel at 22:57, 9 October 2019

2019-10-09T22:57:14Z

Tfolsom: Created page with "The Elcano repositories are on https://github.com/elcano There is a separate repository for each microprocessor: * LowLevel: Drive by wire * HighLevel: Localization, mapping a..."

2019-10-02T23:30:16Z

Created page with "The Elcano repositories are on https://github.com/elcano There is a separate repository for each microprocessor: * LowLevel: Drive by wire * HighLevel: Localization, mapping a..."

New page

The Elcano repositories are on https://github.com/elcano
There is a separate repository for each microprocessor:
* LowLevel: Drive by wire
* HighLevel: Localization, mapping and path planning
* Transceiver: Remote control transmitter and receiver
* Sonar: Obstacle detection from ultra-sound
* Sweep: Obstacle detection by laser
* QDED: Raspberry Pi Vision based on quadrature disambiguation edge detection
* General: for items that are shared between processors.

In the past, all code was in the single repository Elcano/Elcano. That repository has been archived. Any useful files from it should be copied to the appropriate repository.
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. For instance, fork Elcano/Transceiver to Jane/Transceiver. Both of these repositories live in the cloud. You would then download 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, the next st ep 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 xmit the current directory.

git status // should show nothing changed

git add 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.

=== 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.

@@ 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.
-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 one overwriting the other'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.
 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.
@@ 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.

@@ 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.
-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. 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 ==

← Older revision		Revision as of 22:57, 9 October 2019
Line 1:		Line 1:
−	~~The Elcano repositories are on https://github.com/elcano~~
−	~~There is a separate repository for each microprocessor:~~
−	* LowLevel: Drive by wire
−	* HighLevel: Localization, mapping and path planning
−	* Transceiver: Remote control transmitter and receiver
−	* Sonar: Obstacle detection from ultra-sound
−	* Sweep: Obstacle detection by laser
−	* QDED: Raspberry Pi Vision based on quadrature disambiguation edge detection
−	* General: for items that are shared between processors.
−
−	~~In the past, all code was in the single repository Elcano/Elcano. That repository has been archived. Any useful files from it should be copied to the appropriate repository.~~
	Working with Git		Working with Git

@@ Line 1: / Line 1: @@
-Working with Git
+== Why we use Git and GitHub ==
 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. For instance, fork Elcano/Transceiver to Jane/Transceiver. Both of these repositories live in the cloud. You would then download 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, the next st ep is to upload it.
+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.
 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 xmit the current directory.
+Suppose that on your PC you have updated the file xmit/RadioControl_rf69/RadioControl_rf69.ino.
 git status   // should show nothing changed
-git add RadioControl_rf69/ RadioControl_rf69.ino
+git add xmit/RadioControl_rf69/RadioControl_rf69.ino
-git commit -m “Removed a delay statement that blocked while waiting for an ack”
+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.

← Older revision	Revision as of 00:51, 10 October 2019
(No difference)