Today, working with GitHub is a fundamental skill.
Most libraries and projects reside on GitHub, and we have to know how to use them.
GitHub can also enhance our work procedure, and a lot of employers will ask you for your
GitHub account or will check it out before they invite you for an interview.
So GitHub seems to be at least as important as LinkedIn for a professional developer’s
career.
This video will teach you the basics to start with GitHub and use it for your Arduino projects.
And I promise: We will avoid the command line!
Grüezi YouTubers.
Here is the guy with the Swiss accent.
With a new episode and fresh ideas around sensors and microcontrollers.
Remember: If you subscribe, you will always sit in the first row.
In this video, we will: - Learn the difference between Dropbox and
GitHub - Download a library and a project from GitHub
- Create a “fork” from a project for our own purpose
- Create a new project and publish it to GitHub - And finally, we will create a pull request
Let’s start with the basics: GitHub is like a remote disk drive where developers store
their software in the cloud.
Similar to Dropbox, Google Drive, or OneDrive, they work with data on their computer.
GitHub contains only a copy.
So why not just use Dropbox?
The most significant difference between Dropbox and GitHub is the synchronization between
the data on the PC and the cloud.
Dropbox is very convenient.
As soon as you change something on your local computer and are connected to the internet,
the cloud copy is updated automatically.
And your local copy is changed as soon as the file on Dropbox is changed.
So both are in sync nearly all the time, and you get an exception message if both versions
were changed at the same time.
Then you are on your own to deal with the situation.
This automatic copying is the reason I suggest all my friends to use Dropbox or another cloud
service for their documents.
What is a significant advantage if you work alone with unrelated documents can become
a nightmare if you work with related documents or collaborate with others.
The core of GitHub is a staged synchronization for the copy process and its extension for
teamwork.
In addition, it offers a few other features like nicely presenting your project.
Recently, other functionality was added, which will not be covered in this video.
But what is wrong with the sleek copy process of Dropbox?
Let’s look at a simple example: If we download a library from GitHub, we assume it works.
But during their work, Software developers often have unfinished or wrong code.
Only after tests can they be sure it works.
Imagine that the developer works on enhancing this library, and he would use Dropbox.
Then it would be easily possible that our downloaded library would not work because
the developer's errors would also be copied to the public version of the library.
Remember: Dropbox copies all changes nearly immediately.
This would not be acceptable.
At least not for me.
This is why software developers work in commits and releases where they bundle changes and
test them before making them available.
How does this work?
As said before, developers store their files on their PCs.
Specialized software keeps track of all changes they make.
When they are confident that they have a working solution, they “commit” these changes.
They even add the purpose of the changes for documentation.
All these changes stay on their PC.
This data becomes visible to others only if they “push” this packet to GitHub.
So there is always a working solution available for download.
As a first example, we will download a library not available in the Arduino IDE.
If we go to “code” and download ZIP file, we should find a file with the name of the
project plus “main” in our download directory.
You can quickly unpack this file and store it in the Arduino library directory.
If the developer created a new release and you wanted to update your version, you had
to download the new ZIP file again.
You will lose all your changes in this process because all files are overwritten.
This is ok for libraries but usually not for projects.
A small detail: The “main” extension is always added to the name of the ZIP file when
we download the “main Branch.”
Branches are used to distinguish between different versions of a project.
In this example, we used GitHub just as a cloud drive.
The same could have been done with Dropbox or so.
No big difference.
For the following steps you need an account.
For most of us, a free account is sufficient.
I created an account called “YouTubeDemoAccount,” and I will use it as your account for the
rest of the video.
Let’s use my Wi-Fi sniffer project as the next example.
We find it in the SensorsIOT repository on GitHub.
The first we see is that the project is five years old.
But at least it seems to be maintained.
The last change was done four months ago by guidokanschat —a good sign.
We also see the reason for the last change: It was adapted to the new version of the ArduinoJSON
library.
Very good!
If we dig deeper, we see that only one file was adapted.
He had to make quite some changes.
The red stuff was deleted, and the green lines were added.
So we are happy he did it, and we can save the time to do it ourselves.
We also find a short description of the project in the readme.md file.
Next we will use the GitHub processes for the copy.
Instead of downloading a ZIP file, we hit “Open with GitHub Desktop.”
If not already done, we are asked to install the “GitHub Desktop“program.
The desktop tool opens and proposes a folder, and the project name is automatically added.
Now we can go to this folder and work on the project using the Arduino IDE.
Let’s assume we want to change the Serial speed to 9600 and save the file.
If we go back to GitHub Desktop, we see that this change was recorded.
The 11500 was removed, and the 9600 inserted.
So GitHub Desktop kept track of all our changes.
It does this job also if it is not opened, BTW.
As said before, these changes are only in the directory on our PC.
On GitHub, nothing changed.
If we want to copy this change to GitHub, we can add a comment and “commit” it.
Now the change is packaged but still on our PC.
We could add a second or a third commit if we have other changes.
Or we could revert the change and go back to a previous version.
This is particularly valuable if we work on several files in parallel.
When we are ready, we can “push” our change to the GitHub repository.
But why are we asked if we want to create a fork?
What is a fork?
A fork is a copy of the original repository in your account.
But why is this necessary?
Because you are not the owner and therefore would not be allowed to write directly into
my repository.
So GitHub desktop automatically creates a copy or a fork.
This fork is placed in your repository on GitHub and is owned by you.
Next, you are asked whether you want to use it for your own purpose or if you want to
join the project team.
In most cases, we select “For my own purposes.”
If you check now your GitHub repository, it contains a “fork” of my repository.
But it still does not contain your change.
We still have to “push” it to GitHub.
Now you see the change in your repo.
My repo has not changed, BTW.
So you were able to download a project to your computer, change the code, and store
the change on GitHub in your “forked” repository.
Your project stays independent from my project unless you synchronize your fork.
The synchronization process of a fork is not part of this video.
Later we will see the opposite direction: You will contribute your enhancement to my
project.
But first, we will cover the next important use case: Creating a new project.
This is easy because we already understand the process of GitHub.
In GitHub Desktop, we create a new repository by giving it a name.
The path should already be ok.
I propose to tick “initialize with a Readme” and “MIT license.”
Done.
What do you think we will find on our PC?
And on GitHub?
You are right.
A new directory is available on our PC.
It only contains some administrative files.
Let’s check GitHub.
The new repo does not yet exist.
Why?
Because we did not publish it, of course.
So let’s publish the new repo but keep it private.
That is the usual case till your project has a reasonable level.
Then you can change the visibility to “public.”
After publishing, a copy of our PC files is available on GitHub as a private repository
with a readme file and an MIT license.
Now we can start and create an Arduino Project and save it into our PC project directory.
Of course, I use a Blink sketch for my demonstration.
Because it is the first commit, I call it “initial.”
As soon as I push it to GitHub, we find it there.
Cool.
Our first project on GitHub.
Now our fame can begin!
This was quite simple.
From now on, we can work as before with the forked project.
The last process I will cover is how to contribute your “speed” change from before to my
project.
Last time, the push to my repository did not work, and you had to create a fork.
So we will try a different way.
Your change is still available in your directory and your repository on GitHub.
How can we bring it into my project?
The easiest way is to go to your GitHub repository, where you see that your project is one commit
ahead of mine.
This is your change of speed.
If we press “contribute,” you can open a “pull request” to contribute your change.
If you press the button, you see the changes and that your request is able to merge.
This means that your code will not harm my project because I did not make any changes
in parallel to you.
Finally, you can add a short comment to explain your idea to the creator and press the button.
Done for you.
Now we change to my account.
Here we see that one pull request was made, and we can see that it is yours.
I could easily accept it because it would not create any problems.
Here I would see if issues exist.
For example, if I had changed the same lines as you during my development of the new release.
Like that, I could make the needed adjustments.
This is a significant advantage of this GitHub process.
Can you imagine how complicated it would be to keep track of all changes if we used Dropbox?
But of course, it makes no sense for me to use a lower speed.
This is why I refuse the pull request and add a comment.
Your project still keeps the change, BTW.
These were the processes I wanted to show today.
But, of course, there is much more to learn, and you find plenty of videos about every
aspect of GitHub.
But be warned: Most of them use the command line!
We also have to care about one crucial thing: Keep confidential data like passwords on our
PC even if we publish our project on GitHub.
Let’s put sensitive data in a separate file and name it “credentials.h”.
It appears in the change list, and if you committed and pushed it, it would appear on
GitHub.
To avoid that, you must inform GitHub.
That can be done by changing the repository settings and adding the credentials files
to the “ignore” list.
After saving, a gitignore file appears, and the “credentials.h” file disappears from
the change list.
It is still in your directory on the PC but never will be copied to GitHub.
Very good.
And very important because if you pushed your credentials to GitHub once, they would stay
there as a part of the change history visible to everybody.
It is tough to remove them later.
So create the gitignore file as soon as possible.
Gitignore files are also used to keep not needed files away from GitHub, BTW.
What do we need to keep from today’s video?
- The most significant difference between GitHub and Dropbox or other cloud drives is
the copy process between your PC directory and the cloud
- We saw how to download a library from GitHub using a ZIP file
- We were forced to create a fork when we tried to change a repository of another person
- We learned that when we work in a directory on our PC, GitHub Desktop tracks changes that
can be “committed” to a staging area and later “pushed” to the GitHub Repository.
Dropbox immediately would copy changed files to the cloud, BTW
- We learned why immediately copying all changes is not a good idea for some situations
- We created our first project on GitHub to start our career as a software developer
- Then we contributed a change to the original project by creating a “Pull Request”
- And finally, we learned how vital the gitignore file is to protect our privacy
This was all for today.
As always, you find all the relevant links in the description.
I hope this video was useful or at least interesting for you.
If true, please consider supporting the channel to secure its future existence.
Thank you!
Bye