Microsoft bought GitHub, and everything will be fine!
Hello World! It's Siraj.
and in this video i'll show you how to use GitHub, the safe space for developers across the world.
I'll describe how the Git protocol works,
show you how to make your own repository,
and give you some tips on how to promote your GitHub code via social media. Over a decade ago,
the legendary programmer, Linus Torvalds
was working on an operating system that
had been his pet project for a couple of years
He was constantly making changes
to his code and there were other developers,
who were interested in contributing to the
project as well. He needed a way to
track, how the code changed over time
so, if he messed up, he could easily go back
to a previous version
The simple way would be to continuously rename
every new version of his source code
but, this was cumbersome. A better way would be to
use some kind of light-weight protocol to
track those changes over time. This would also help him
work with other developers, as it would give
them a collection of notes on the most recently worked on project files
as well as a nice chronological history
of what had changed. There were existing tools out there, but
Linus was not happy with any of them, as
in his hilariously strong opinion, they didn't worked
well enough. for that reason, he wrote the Git protocol
to solve his problem.
And he used it to help him work on his Operating system, Linux.
Even though, there are other version control
systems out there, Git has since
exploded in popularity becoming the most used
It's now at the heart of pretty much every modern
development workflow and the popular website
github.com uses the git protocol to
host code bases and allow developers to
work together with a single shared interface
Git has a lot of different commands, and
it's architecture can be confusing
if it's your first time trying to understand it
to make git more intuitive,
let's use the analogy of an auto company, like Tesla
Let's say Tesla has to release a new version
of it's Model S every year, with slightly
updated features, the different teams of car
designers at Tesla have a year-long
plan to execute those features
for the latest version. And along the way
each team has to make sure, their changes
support the changes from other teams
So, if we're on the body-design team,
We need to create a body design
that doesn't just look good.
It has to work in tandem
with the new features, that, say, the interiors
team is putting in the car, like flamethrowers
How do we best organize our workflow
such that we can accomodate all the teams?
As we are developing the body for a 2019 version,
there are actually four versions of the design
that exist at any given time
There's the Live version, that's the current version that's
already on the market, that customers know about
There is the currently planned version for the next year
that will eventually go live once all the teams agree
This represents the remote repository. There's our own latest,
improved body design version that
takes into account suggestions from other
teams
That's yet to be presented to the rest of the team for approval
This represents the local repository. And
finally, there's a design we are developing
and excited about. It still needs to be tested
and reviewed by the team.
This is the staging area. Each stage represents a
different level of commitment to the body design
and similarly in a code base,
our code must pass through four stages
before it goes live, just like in the car design process
this is a great thing. We wouldn't
want to just draft up a car design
and immediately decide, that hey,
this is the final 2019 design. The whole team
has to agree upon whether our design works
in harmony with the other changes
that are being made, it's a democratic process
unlike Apple. Git has a set of commands
that we can find via a simple cheat-sheet
each has it's own use case
We can use 3 commands in particular, to
highlight the different stages of review
that our design must go through before it goes live
Each stage further lowers the risk
that will make a decision that conflicts with features
built by another team
git add declares that we've finished a full design
and that we feel good about it. It stills need to be tested
and reviewed, though, as this design
enters the staging area. Git commit means
we feel fully confident in the design
we've put it through all our standard tests
and our features like revolving side-mirrors,
they're all in place. This design is now copied
from the staging area into the local repository,
ready to present to the other teams
Once, we're ready to present our car to the other teams
we can copy our design from the local
repository to the remote repository
we had the git push command
the remote repository is hosted in the cloud
while, our local one is hosted on our machine
and once all the teams are happy
with the new features, we can deploy it to
our website or mobile app, in production
this isn't actually a git command, it just represents
the process of going live to production
So far, we've assumed that we are all building just
one new version of our car at a time
But the reality is, that our car actually has
3 variations.
Each with slightly different body design
They have pretty much all their features in common, except
for the body-design. We could
just make new repositories for each
but since they share so many in common,
we can just create branches for each.
Branches let us maintain multiple versions of the same code base
Each branch will have a few slight
differences. And if the marketing team
learns, that hey, there isn't a demand for a certain version
of our car, but it would be nice to have a certain feature of that car in our main version
We can use the merge command to integrate two branches
This eliminates one branch,
but brings the features of that branch into a single new branch
Let's say a team pushes a new feature like a car dashboard
to the remote repository, we can update our local repository
with git pull, pulling the new changes
but if those changes conflict with our repository
we have what's called a "merge conflict"
we have 2 options to resolve this, we can either
tell that team to revert their changes to what they were previously, or
We can change our own body design so that it fits the new dashboard
then push an updated version to remote to resolve the conflict
Git helps us track all these conflicts
and quickly points out
the exact lines that are in conflict.
So, let's go ahead and create our own repository, then put it on github
We can sign up for github pretty easily on the website
after entering a few credentials
We want to add a picture and a description
since it's essentially a social network for developers
Once we do that, we can download the latest version
of the git protocol and install it
after that's done in command line, we can set up git
so it links up with github
We define our github username and e-mail
using the git config command, the same ones we used on github.com
Then, we can create our first local git repository
via command line using the git init command
We can check the status and see that we have absolutely
nothing to commit right now
so, we'll just create a new file
and add some code to it.
Now, we want to push these changes to github
so, we can add it to git, straight to the staging area
This is our initial design
Then, if we're satisfied, we can commit our changes to our local repository via
the commit command.
Before we push our code to the remote repository,
let's create another branch, for fun
then switch to it via the checkout command
We can modify the code a bit here, then commit it.
Now, if we switch back to our main branch,
also called master
We can make another change, just for fun, and commit it.
Now, if we want to merge the changes
from our new branch onto master,
We can, via the merge command
But alas,
There will be a merge conflict
this happens when we work with teams.
Each developer working on their own branch
luckily, git let's us resolve these conflicts
by seeing the exact line of code in question
we can resolve it locally to match
Then commit the resolution
This is why, git resembles a tree
different branches, each with different commits
can all represent nodes in a tree
all leading up to the master node
Now, we can push our code to github, but first let's create an empty repository on our new github account
We'll copy the link it gives us and add a new remote
Then, we can push to that remote via the push command
and if we go to that repository on github,
we can see our code there, how dope is that!
Github is a social network and you can follow other developers
to keep up to date with their latest code.
the more developers that follow you, the more likely developers will contribute to your open source project
Currently, Linus Torvalds is the most followed developer out of 28 million on github
and right now I'm number 15, so watch out Linus :P
I found lot of success promoting my github profile
by using my social media accounts as a distribution channel to github.
and good documentation goes a long way to getting developers to follow your code.
promoting code directly leaves a very niche audience to view it
but if you wrap it, with say, a video or blog post or podcast,
some kind of explainer content in general, then,
you'll be more likely to get people to actually view the code
Git and GitHub are both a lot of fun
and I've listed some great learning resources for you in the video description.
So, definitely check them out.
Ready to commit to more?
Push that subscribe button and my heart will merge with your's.
For now, I've got to resolve a conflict. So, thanks for watching :)