In previous posts we talked 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 means the normal evolution of the tool, language or software. The tools we create are not static, it always needs to improve and enhance their behavior and results.”

The question now is how can I assign versions to my own programs? and how can I deal with all the changes?

Well let’s see the next use case

This is the way we worked before Git. It was a time when we had everything in our machine, track changes manually and deploy code using Filezilla which is a tool that even today exists and helps you to deploy to a server machine shipping each file changed separately… it was a mess

So we have some keywords here:

The first thing we have to clarify is that Git is different from GitHub. Later in this same post we’ll see the differences in more detail

This is all about “Control”. When your code starts growing you have to take control over that growing because if you lose it, you can also lose the project itself. That means that any change (big or small) could become a real headache. You have to control each change, you need a way to easily 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 web sites, 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. Revisions can be compared, restored, and with some types of files, merged.

The need for a logical way to organize and control revisions has existed for almost as long as writing has existed, but revision control became much more important, 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 (as well as complex) revision control systems are those used in software development, where a team of people may concurrently make changes to the same files.

Version control systems (VCS) are most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processors and spreadsheets, collaborative web docs and in various 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 next link: https://en.wikipedia.org/wiki/Version_control

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

In version control systems, a commit is an operation which 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 easily. In this context, a commit within a version control system is protected as it is easily rolled back, even after the commit has been applied.

Deploy is the action to send code to a server in the cloud. Is much easier to deploy code to production if you’re using version control management, because everything is well organized and coordinated. With a version control you can deploy just the changes made by you or other developers, 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 a bit confused about the differences between Git and Github, so here you can find them

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]"

Now is the memento 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 next webpage: https://git-scm.com/downloads and choose Windows

Now click on the blue link called: “Click here to download”

Then “Save”

Then “Run”

And now follow all the wizard steps clicking “Next”

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

Click on “Git Bash” and it will display the console with Git running on it

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, while you don’t have to install Github, you need to go to the webpage, create an account and then connect it with your local Git in your machine. 

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

I’ve created a folder with this 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?

So far we’ve created a Ruby file, and now it is tracked by git. How can we see the different versions? With next command:  

$ git log

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

Also another thing to have in mind is that currently we have the code just in our local machine. Here is where Github plays an awesome 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 (some 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 is a place here 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 repository, please hit the next link: https://en.wikipedia.org/wiki/Software_repository

Inside your account click on 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). You can check private or public, in my case I want to create this repo as “Private” (they are free). Finally click on green button called “Create repository”

You’ll se now next screen

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

$ git init

$ git add README.md

$ 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 already the code in Github. Let’s refresh our Github page

Right there we can see our recently created index.rb file

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

Hope you learned a lot

Thanks for reading

DanielM