2019-04-05

Basic Concepts About Git and Github

In previous posts, we've been talking about Versions and Releases:

We've said in those posts that: "One of the first things you need to understand in the software development world is that open source programming languages and the software we create are always attached to a given version. Versions mean the normal evolution of the tool, language, or software. Therefore, the tools we create are not static; they always need to improve their behavior and results."

The question now is how can I deal with changes and versions into my own programs?

Well, let me write a little narrative here:

* Let's suppose that you're working on a given project.
* You've just installed Ruby and Ruby on Rails, and you want to create a web app
* Then, you write the initial skeleton of the app. You did that in just one day, which is impressive!
* You want to save all of this code in your machine, so you've created folders and files to be organized and to have it ready to continue the next day
* Next day, you come to your machine, open the project, and want to continue the coding frenzy
* Now, you've coded the authentication process for the users. With that ready, you've finished another day of coding, then you save the project on your local machine
* Next day, you come again to the project, but this time you want to look back on a change you did on the first day of coding because it seems that there is something wrong there.
* Then you figure out that the best solution is to reverse the changes, but you don't have a way to do it
* Finally, you figure out a way to reverse it, but the code started to get more robust and complicated, and you cannot track all of your changes over the days
* One day, you finally realize that you have to deploy your code to a production server. So you ship your entire code in a single big folder. Maybe in the future, this could become out of your hands
* You made more changes and want to deploy again, so you have to repeat the whole process, and suddenly you feel that you're losing control of the project
* Then the web app grows, you've been doing this for a year now, but now you need help from other developers. The question is, how can you coordinate your work because they'll be doing everything in their own machine, while you in yours

A bit scary, isn't it? But, this is the way developers worked before Git was born. It was a time when we had everything in our machine, tracked changes manually, and deployed code using Filezilla, a tool that even today exists and helps you deploy to a server machine shipping each file changed separately…

it was a mess!

So we have some keywords to study here:

* Control
* Checkpoints
* Deploy

The first thing we have to clarify is that Git is different from GitHub. Later in this same post, we'll see the differences between them.

Control

This is all about "Control." When your code starts growing, you have to control that growth because you can also lose the project itself if you lose it. That means that any change (big or small) could become a real headache. So you have to control each change; you need a way to quickly reverse any change or even work in a ramified way with other developers.

In software engineering, version control (also known as revision control, source control, or source code management) is a class of systems responsible for managing changes to computer programs, documents, large websites, or other collections of information. Version control is a component of software configuration management.

Changes are usually identified by a number or letter code, termed the "revision number," "revision level," or simply "revision." For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Modifications can be compared, restored, and merged with some types of files.

The need for a logical way to organize and control revisions has existed for almost as long as writing. Still, revision control became much more critical and complicated when the era of computing began. The numbering of book editions and of specification revisions are examples that date back to the print-only era. Today, the most capable (and complex) revision control systems are those used in software development, where a team of people may concurrently make changes to the duplicate files.

Version control systems (VCS) are most commonly run as stand-alone applications. Still, revision control is also embedded in various types of software such as word processors and spreadsheets, collaborative web docs, and different content management systems. Revision control allows for the ability to revert a document to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend against vandalism and spamming in wikis.

If you want more details about version controls, please hit the following link: https://en.wikipedia.org/wiki/Version_control.

Checkpoints

With the example we mentioned above, it is easy to recognize the necessity of different checkpoints to track the other changes. Each bunch of changes can be a new checkpoint. This is also known as a commit inside the Git jargon.

In version control systems, a commit is an operation that sends the latest changes of the source code to the repository, making these changes part of the head revision of the repository. Unlike commits in data management, commits in version control systems are kept in the repository indefinitely.

Thus, when other users do an update or a checkout from the repository, they will receive the latest committed version unless they specify they wish to retrieve a previous version of the source code in the repository. Version control systems allow rolling back to previous versions quickly. A commit within a version control system is protected as it is easily rolled back, even after the commit has been applied.

Deploy

Deploy is the action to send code to a server. It is much easier to deploy code to production using version control management because everything is well organized and coordinated. With version control, you can deploy just the changes you or other developers make, not the entire code again.

Because of the version control, we don't have to use Filezilla anymore, and now we can use modern techniques to ship code to production or even to other environments like staging.

Now you could be confused about the differences between Git and GitHub, so here you can find them.

Git

The name given to Git is "Version Control." The name speaks by itself. Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems).

Installing Git in Linux

$ sudo apt-get update
$ sudo apt-get install git
$ git --version
$ git config --global user.name "Daniel Morales"
$ git config --global user.email "[email protected]"

Installing Git in Windows

Now is the moment to install Git in Windows, and we have to say that there are a lot of steps in the Wizard installation process. The only thing you have to do is click on "Next" with all the default options. So let's check the screenshots.

First, go to the following webpage: https://git-scm.com/downloads and choose Windows.

Now click on the blue link: "Click here to download."

Then "Save"

Then "Run"

And now follow all the wizard steps clicking "Next" in all of them.

Now that we finished, we have to go to the search bar of our machine and type Git, and see the following options.

Click on "Git Bash," It will display the console with Git running on it.

Github

GitHub is a company that provides version control in the cloud using Git behind the scenes. You need to install Git in your local machine first; while you don't have to install GitHub anywhere, you just need to go to the GitHub webpage, create an account and then connect it with your local Git in your machine.

Just go to the next page and create your account: https://github.com/.

Main commands to run with Git and Github

I've created a folder in my local machine with these commands.

$ mkdir danielmorales_project/git_and_github
$ cd danielmorales_project/git_and_github
$ git init
$ ls -la
$ touch index.rb
$ git status
$ git add .
$ git commit -m "Add Index Ruby File"

What did we do here?

* We have created a new folder with these commands: $ mkdir danielmorales_project/git_and_github
* We go inside the folder with this command: $ cd danielmorales_project/git_and_github
* We've initialized Git. This is a mandatory step to use Git on any project: $ Git init
* We listed hidden files with this command: $ ls -la
* With touch, we've created a file named index.rb
* Then we checked the status of the Git with $ git status
* Then, we added the changes to the staging phase in Git: $ Git add . (the dot means that we want to add all the files inside the current folder)
* Finally, we commit the changes, so we have our first checkpoint of changes: $ Git commit -m "Add Index Ruby File" (even we've given a name to the commit to quickly identify it in the future)

So far, we've created a Ruby file, and now it is tracked by Git. How can we see the different versions of our project? With next command:

$ git log

Now we've just one commit, but we'll be creating more and more commits over the days, and they'll appear here.

Also, another thing to remember is that we currently have the code just in our local machine. Here is where Github plays a tremendous role. We want to ship this same code to the cloud inside Github, and with that, we'll be sure that other developers can access it and download it, and even if we lose our local folder (for some reason), we can download the last version of the code which is hosted in Github.

So let's connect our local Git and the Github account. Inside your Github account, you've to create a new repository. A repository (in GitHub jargon) is a place where you can organize and save all of your code, files, and folders for a given project. Usually, you create a repository per project. If you want to know more about repositories, please hit the following link: https://en.wikipedia.org/wiki/Software_repository.

Inside your account, click on the right green button called "New" inside the repositories tab:

Let's call the repository with the same name as the local project (obviously, you can give any name to the repository). Then, you can check private or public; in my case, I want to create this repository as "Private" (they are free). Finally, click on the green button called "Create repository."

Note: leave another checkbox empty

You'll see how the next screen.

Right there, you'll find the instructions to connect your local git project with the Github repo… but wait a moment, we already ran some of these commands like:

$ git init
$ git add .
$ git commit -m "first commit"

So we have to follow just the other steps.

git branch -M main
git remote add origin [email protected]:danielmoralesp/git_and_github.git
git push -u origin main

Let's do it

We got an input that says that we've shipped the code to Github. So let's refresh our Github page.

Right there, we can see our recently created index.rb file. This is awesome! We have a way to track all of our changes now.

Later, we'll be seeing more details about Github, but we have the differences clear and the basic concepts for now.

Hope you learned a lot

Thanks for reading
Daniel Morales