How to Use GitHub
- Articles, Blog

How to Use GitHub

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 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 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 😛 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 🙂

About Ralph Robinson

Read All Posts By Ralph Robinson

100 thoughts on “How to Use GitHub

  1. Can you make a tutorial on git-ssb? It's decentalized and can't be completely owned by one single entity.

  2. Your display of Linus Torvald's profile on Github is a GROSS misrepresentation of Linus's feeling towards Microsoft. Linus is a god of open source and the creator of Git. Showing his profile on Github may give people the impression that he endorses or is okay with Microsoft or Github but he has commits on there since 2007. Torvalds on Microsoft

  3. I would love to see your approach and hear your thoughts about GIT and CI (such as Travis CI with Github) w.r.t. development and deployment of models.. 😎👌🏼

  4. Recently I read on Reddit about you not being able to code, copying other people's code and spamming Reddit without contributing to them and that's why you got banned from Reddit. My question to you is it true what they say, is most of your code broken?

  5. Thanks so much! I just started using GitHub for ML projects about a week ago, and it's made my life a lot easier. It really helps to have a simple, compact explanation like this available.

  6. if coffee is empty keep coding, else fill the coffee. should it not be, if coffee is not empty, keep coding else fill the coffee?

  7. I found the coffee starvation or coffee overflow funny. Was this an intentional joke or a mistake? 😉

    Also, you got the history of git wrong. Torvalds was quite happy with a scm called BitKeeper but not everybody liked it, because it was a proprietary/non-free software. It had some evil restrictions in its license, like prohibiting reverse engineering. When Andrew Tridgell used telnet to connect to the BitKeeper servers and typed in the command "help" and got a list of commands, he was accused of reverse engineering it. He was banned from using it and this started the last discussion about the use of proprietary/non-free software for the kernel development.

    A short time later, Torvalds released a few tools, nothing big but a good starting point. You had to combine a few commands to add filed to the index, writing tree objects, committing them into a commit object. It showed the basic idea but wasn't very usable. Some shell scripts were added and it became usable and very comfortable. Sometime at the end of 2006 I moved all of my projects from tla (tom lord's arch), svn and cvs to git. I have thrown all the other scm's away because they felt like garbage.

    Later the shell-scripts were replaced by built-in commands written in c. This has increased the portability of git, but unfortunately it made the code more complicated and less hackable. I still suggest anyone to checkout some old version of git, v1.0 is good and has all those easy shell skripts. Not to use it, just to learn from it. Those shell skripts and tiny c-programs are a wonderful documentation of the inner workings of git.

    And now to github, gitlab and so on: Nobody should make himself or a project dependent on those platforms! Git itself is made to be a completely distributed peer-to-peer system. It uses real social networks, you always know the email-address of a project or subsystem maintainer and you can send him a patch created with git format-patch. If the patch applies without conflict, you are done. If you have many changes, you can upload a git repository to some random web space and send a link to it per mail (the original pull request). And if you are completely dependent on some graphical website, then install the gitlab software on your own server. If you just want to visualize the history of your git projects, you can install gitweb or cgit which don't use as much resources as gitlab. There are also commandline tools to visualize the history, like gitk. The beauty of git is, that it can work offline. So don't create useless dependencies to web services.

    TL;DR, sometimes I write too much, sorry. 😉

  8. Nice idea, but I think you should have gone slower on the actual explanation. You explained slower the car example but went faster when you actually showed code. And also the audio explanation is quite out of sync to what the screen is actually showing. If you improved on those two points I think the video would be quite better!
    Good job anyway, it's a nice idea to try to teach this to people, I still have a bit of trouble using github and when I started I found almost no easy down to earth resources to learn.

  9. I like how you're speaking more slowly and explaining more about why something is useful rather than just jumping right into code. It makes it much easier to listen to you.

  10. Wow! Very well done explanation of github. I really understood that. I've used stuff from it. Absolutely love linux. I got on board with linux when it came out and have always used it on a pc. Everybody needs at least 2 computers with a linux operating system.

  11. i personally know github, but i think its really great that you make this video, especially since all of your tasks need to be linked with github, you are so nice =)

  12. slow down siraj your too fast i think you have covered 30minute content in 11 minutes.
    I Like the Presentation and animation.

  13. Here we go… Infomercial made by Microsoft….the safe space is called " Gitlab" or "Gittorrent"….. Microsoft is a spyware, so they will inject malicious code from github

  14. This is probably easy to understand If you know GitHub, but I don't understand shit 🙁 Like what is git fetch at 4:35…

  15. From 3:05 you start to list repositories on a reverse order in which they are shown. This makes difficult to follow the description and it makes the whole video untrusty.

  16. Help please Siraj. I am trying to startup a digital school with just one subect. My ISP provider says I cannot have an IP static.
    What can I do ?
    I follow your videos and will switch my focus to AI based teaching learning.
    Thanks a lot. Jose

  17. Poor programmer .. that code in 0:40 doesn't make sense 🙁
    Why fill coffee ☕ if it's not empty? Why keep programming and not fill the ☕ if it is empty? 🙁

  18. The transition animations are super annoying o.O Like the slow moving text that you cant see the full sentence of at 5:00, and then there are even arrows to show what he is talking about while you cant even read the point that arrow is pointing to.

  19. Btw Microsoft is making a buy bid for this platform … There goes private development. Watch those terms of service boys and girls

  20. man your stuff is good, but gotta give you a thumbs down because you are overwhelmingly annoying. You are not nearly as cool as you think you are, specially with your oddly looking haircut. but your material is decent.

  21. This video needed a pull request…
    Knowledge of Git is sooooo important for any professional dev (hobbyists can benefit from it too), but the quality in some parts just isn't up to his regular standard…

  22. Good video for who have already known how to use git and github but for begginers there are too many abstractions that will make them overthinking and feeling lost when actually try using a new tool

  23. Great intro, but only one complaint. The animated graphics often felt like they were out of sync with the narration. Confusing at first, but eventually made sense.

    On the plus side, the chart at 4:40 is especially informative. Not having used GIT very much, I was a little confused by the difference between commit and push, for example. The chart quickly clarifies this and other concepts.

    Nice job.

  24. I always advice my junior engineers to start with git UI tools with visual diffs like meld. This way they could strengthen their git workflow (like doing visual diffs review before committing the code) and could easily get familiar with git.

    I met some junior devs who just use git bash just to blend in with the gurus they see on the web and when they do tasks that could be quickly done by a git ui tool, they struggle and do lots of googling (e.g. doing a diff of a file on two different branches wherein you need to type a lot to achieve this in git bash, but this will be just a series of mouse clicks on a git ui tool).

  25. Hay bro not sure if you wanna work on this idea etc. But I'll give you a quick run down…literally for years I've been watching sports, especially college and NFL football. And these dudes are throwing games for certain. Maybe a lot of folks doing machine learning don't watch sports….but the idea is simple…if you watch a sporting event, and see a player who has made a play that looks, quote un quote 'fishy' you would circle his name so to speak, with other variables, like odds on the game etc… not sure best way to build data sets etc…not sure if the motivation would be to make money, betting is a slippery slope. I just hate seeing these throw games, and I thought maybe using machine learning it could be a fun way to get ahead of the curve. Thanks for your time….let me know if you have any ideas etc….ok…..peace!!!!!

  26. in 3:15 you are showing the definitions in the opposite order than you are describing them. And would you use the "2017 model" you know people might still watch this years after right?

  27. You've got to admit that you are definitely not the one for such videos. You just keep blabbering some random shit and also you expect new comers would know all these things. Go slow in explanation bruh. you are just telling the meaning of what you are typing and not explain how it works or how to do it.

Leave a Reply

Your email address will not be published. Required fields are marked *