A version control system, in the simplest terms, allows you to maintain different versions (snapshots) of your code while your code is growing.<\/p>\n
And this gives you the following benefits.<\/p>\n
1- disaster recovery<\/strong><\/p>\n Since a version control system allows you to have different versions of your source code. If your newest version is not working for whatever reason (may be it’s that new hire), you can easily roll back to a version of the code that you know is working.<\/p>\n 2- collaboration<\/strong><\/p>\n Version control systems facilitate collaborative development.<\/p>\n Development as a team would have been a nightmare without systems like git (and others).<\/p>\n With that said, git is the most popular version control system there is nowadays. And this is likely to last for some serious time. You can quote me on that.<\/strong><\/p>\n So now that you are sold on the importance of git, how do you learn git?<\/p>\n In the rest of this article, I will cover the 5 steps that you need to progress through while learning git.<\/p>\n I will do this by walking you through a very basic tutorial.<\/p>\n For each step, I’m going to cover the basics but it’s up to you to go ahead and make sure you understand each topic in depth by fiddling with git yourself and reading more resources.<\/p>\n Follow these steps, in the presented order, and make sure you study each step thoroughly before you move on to the next one.<\/p>\n Here is what this article will cover.<\/p>\n To avoid any confusion, and to make sure that your learning process starts out with the right mindset, I want you to completely forget that Github<\/a> exist.<\/p>\n The reason is that many beginners confuse git with Github.<\/p>\n They are two completely separate things.<\/p>\n By pretending that Github doesn’t exist, you will be able to gather the git concepts much faster.<\/p>\n In this step, all you need is your laptop.<\/p>\n You don’t even need an internet connection.<\/p>\n Let’s get started.<\/p>\n Let’s say you want to start working on a new coding project. Let’s call it helloworld.<\/strong><\/p>\n So you go ahead and create a directory called helloworld<\/strong> where you will store all your project source files.<\/p>\n Now because you are a smart person, you know that you need to create a git repo in order to version control your source code.<\/p>\n Doing so is stupid easy!<\/p>\n Just head to the helloworld<\/strong> directory and run the git init<\/span> command:<\/p>\n And just like that, you have a git repo.<\/p>\n It’s time to start actually writing code!<\/p>\n For simplicity, let’s create a README.md<\/strong> file and a Python hello world<\/em> program hello.py<\/strong><\/p>\n By creating these two file, you have populated your directory<\/strong>. However, your git repo<\/strong> is still empty!<\/p>\n The first rule of git is, your working directory is NOT your repo<\/p><\/blockquote>\n The reason your git repo is empty is because you need to explicitly tell git to take a snapshot<\/strong> of your code.<\/p>\n Each snapshot (or version) of your code is called a commit\u00a0<\/strong>and each commit is uniquely identified by a hash which is a function of the content of your source files, some metadata, and other things.<\/p>\n To tell git to take a snapshot of your code, you do so by first staging the files that you created or modified and then committing them.<\/p>\n Staging a file means that you are telling git to take the changes in that file into consideration the next time you take a snapshot of your code.<\/p>\n For example, to stage\u00a0hello.py<\/strong>, you run the git add<\/span> command.<\/p>\n Cool, now git knows that the next time you take a snapshot of your code hello.py<\/strong> will be included.<\/p>\n Committing your changes is the actual act of taking a snapshot of your code.<\/p>\n But again remember that this snapshot will only contain the changes in the files that you have staged in the previous step.<\/p>\n These changes could be adding, removing, or modifying the contents of a file.<\/p>\n In our case, there is one change that we staged and that is creating a new file hello.py<\/strong><\/p>\n Even though we also created a README<\/strong> file, git will not see the new file until it is staged as well.<\/p>\n To create a commit, you use the git commit<\/span> command and you also provide a nice, descriptive message about this commit.<\/p>\n Perfect.<\/p>\n Let’s also stage and commit the README.md<\/strong>.\u00a0 By now, you should have two commits in your repo.<\/p>\n Each commit you make is stored in the git repo with a pointer to its parent commit, much like how a linked list<\/a> would look like.<\/p>\n So if you have three commits in your repo, this is how they will look like, conceptually.<\/p>\n But is it really a linked list though?<\/p>\n Well read on and you will find out!<\/p>\n In fact, git allows you to branch out from the main branch (which is by default called the master<\/strong> branch).<\/p>\n But why? What’s the point?<\/p>\n Assume you have an idea of a new feature that will require a significant change\/refactoring to your existing code and you want to experiment with this idea without risking the stability of your existing codebase.<\/p>\n One way to do that is to create a branch off of master and experiment with your idea risk-free.<\/p>\n Branching is extremely useful especially when you are working on a project collaboratively because it allows individual developers to branch out and code away without stepping on each other’s feet.<\/p>\n Let’s go back to our example and create a branch.<\/p>\n To create a branch, you have to give it a name.<\/p>\n Let’s call our new branch feature<\/strong>.<\/p>\n Use the git branch<\/span> command as follows<\/p>\n Notice that the above command only creates a new branch but you are currently still on the master branch.<\/p>\n In other words, any work you do and any commits you make will be added to the master branch, not the feature branch.<\/p>\n To go from one branch to another, you use the git checkout<\/span> command.<\/p>\n Now let’s modify the README<\/strong> file and create a commit in the feature branch.<\/p>\n Now, let’s go back to master and inspect the README<\/strong> file<\/p>\n As you can see, even though we have modified the README<\/strong> file in the feature branch, this modification is not reflected on the master branch.<\/p>\n Both branches can be worked on completely separately from this point on.<\/p>\n Since we are on the master branch, let’s create another commit here because why not?<\/p>\n May be let’s just modify the hello.py<\/strong> file and make a new commit.<\/p>\n Awesome.<\/p>\n This is how the commits in our git repo look like now.<\/p>\n It is very obvious now that the commits do not form a linked list.<\/p>\n It actually looks like a tree data structure<\/a>, right?<\/p>\n Well in this particular case yes, but in the next step, you will see that it can be transformed into a more generic data structure.<\/p>\n There is no point in branching out without being able to merge branches back together.<\/p>\n In our example above, the main reason we branched out was because we wanted to experiment with creating a new feature (which is in our case a dummy README<\/strong> modification :)).<\/p>\n Now that we know that our feature is working, we want to merge this feature with the master branch.<\/p>\n Git allows you to merge branches in various ways.<\/p>\n But let’s use the simplest one, git merge<\/span><\/p>\n To merge the feature<\/strong> branch with the master<\/strong> branch, make sure you are on the master<\/strong> branch and then run the following command.<\/p>\n If you inspect both files now, you will see that the content of both branches have been merged.<\/p>\n When you merge two branches using git merge<\/span>, git actually creates a new commit that has two parents from both branches.<\/p>\n That said, this is how the commit history looks like now.<\/p>\n Now it’s not a tree anymore, is it?<\/p>\n Rather, it is a DAG<\/a> (directed acyclic graph) with each commit pointing to its parent<\/strong> or parents<\/strong>.<\/p>\n Life is not always a bed of roses.<\/p>\n Sometimes when you try to merge two branches, conflicts will happen.<\/p>\n A conflict<\/strong> essentially means that two branches have modified the same part(s) of the same file(s).<\/p>\n When this happens, git will prompt you to resolve the conflicts first before resuming the merge process.<\/p>\n Needless to say, you have to be very careful about how you resolve these conflicts. Otherwise, bad things could happen.<\/p>\n This is one of the areas where you can easily mess up if you don’t know what you’re doing.<\/p>\n I have seen big chunks of code being destroyed after a merge process! This is not good for anyone, so don’t be that person \ud83d\ude42<\/p>\n Congratulation, now you are ready to fiddle with Github \ud83d\ude42<\/p>\n Finally the time has come.<\/p>\n In addition to your local repo, git also allows you to have copies of your repo remotely.<\/p>\n This is what git remotes<\/span> are and Github is a service that allows you to host a remote git repo in the cloud.<\/p>\n But what’s the point of these remote repos anyways?<\/strong><\/p>\n Well, from a disaster recovery perspective , the more copies of your repo the better. If you accidentally completely hose your local repo, you can still have access to your source code.<\/p>\n From a collaboration perspective, this is where services like github and bitbucket shine.<\/p>\n The remote copy of the repo can act as the shared, point-of-truth repo for you and your colleagues.<\/p>\n Working collaboratively in this case entails pulling the source code from the remote repo to your local repo, doing your work locally, and then eventually pushing your work back to the remote repo.<\/p>\n Let’s actually create a remote repo on Github for our example project.<\/p>\n Go to this link<\/a> and create a new repository helloworld<\/strong>.<\/p>\n This step creates an empty remote repository for you.<\/p>\n It also tells you exactly how to push your local git repo to Github.<\/p>\n Since we already have a local git repo, let’s push it upstream to Github.<\/p>\n And there you go.<\/p>\n You just pushed your local repo remotely.<\/p>\n Now you have two copies of your local repo.<\/p>\n Now you have a bird’s eye view of what git is, what Github is, and how to go about learning them and in what order.<\/p>\n It is really important, and expected, in this day and age for any software engineer to be a git master.<\/p>\n From here, it is up to you to dive deeper and learn each of the concepts above in great depth.<\/p>\n Good luck \ud83d\ude42<\/p>\n And so much more…<\/p>\n\n
\n
Step 1: Forget about Github, learn git locally<\/h2>\n
First: Creating a git repository<\/h3>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-28-at-9.10.39-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-28-at-9.25.16-PM.png\")
<\/p>\nSecond: Staging your changes<\/h3>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-28-at-9.48.33-PM.png\")
<\/p>\nThird: Committing your changes<\/h3>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-28-at-9.58.45-PM-1.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-28-at-10.16.11-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-5.18.49-PM-1024x606.png\")
<\/p>\nStep 2: Branch out<\/h2>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-5.35.06-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-5.42.32-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.07.48-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.11.21-PM.png\")
<\/h2>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.15.01-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.26.35-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.30.29-PM.png\")
<\/h2>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.37.02-PM-1024x710.png\")
<\/p>\nStep 3: Learn how to merge branches<\/h2>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.50.27-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-6.53.22-PM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-29-at-7.12.01-PM-1024x597.png\")
<\/p>\nStep 4: Learn how to resolve merge conflicts<\/h2>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/2q0mum.jpg\")
<\/p>\nStep 5: Get comfortable with git remotes<\/h2>\n
![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-30-at-8.08.20-AM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-30-at-8.15.43-AM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-30-at-8.20.59-AM.png\")
<\/p>\n![\"\"](\"http:\/\/www.afternerd.com\/blog\/wp-content\/uploads\/2018\/12\/Screen-Shot-2018-12-30-at-8.22.10-AM.png\")
<\/p>\nFinal words<\/h2>\n
Featured Posts<\/h2>\n
\n
Are you Beginning your Programming Career?<\/h2>\n
I provide my best content for beginners in the newsletter.<\/h3>\n
\n
Subscribe now. It’s Free.<\/h3>\n