This series is a very basic Git tutorial for beginners. This three-part series will cover a basic introduction in the first part, branch management in the second and the Git client in the third and the final part.
Even mid-level projects could generate several versions of code. Things start to get complicated very quickly as developers have several versions of code to sort through. There are several directories with different version of code. This presents huge problems for code merge and version management.
Git is an excellent solution for managing various versions of the code and presenting a final version of the code.
Understanding Git and Version Control
Git was originally created by Linus Torvalds in 2005, who envisioned it as a free and open source system for managing all the versions of the source code of a project. Git saves the entire history of the code by creating a repository on the local machine(s) and online servers. Thus, a developer could easily add, commit, merge code and view the logs of the changes.
Git supports branching of code with different test branches during the development phase that are then merged into a single, final master version. The system is ideal for collaboration between teams of all sizes where the pull requests are viewable by all members. All the branches are finally merged into a master branch.
Three Tree Architecture
Git works on the following three-tree architecture:
1. Working Directory
This is the local directory where the developer develops the code and creates different versions of the code by committing the version. This adds to the version history of the code.
2. Staging Directory
Staging directory contains the committed code of the project. This branch keeps track of the changes made in the code. This state also tracks the changes in various branches and notify the developer of conflicts in the code. These conflicts are then resolved and the code could be pushed to the deployment directory.
Repository is the place for deploying the final code after all the merging of the code. Git creates a final copy on the local machine and also create repositories on both GitHub and Bitbucket. I personally prefer Github, as it is more developer-friendly.
Here is the visual representation of the three-tree architecture along with the commands that are used on every stage.
Git Installation on Different OS
To use Git on the local machine, you first need to install the right version for the operating system of the machine. This is a straightforward process. Just go to the Git Scm website and download Git for Windows, Mac or Linux. Next, run the installer file and follow the wizard. Here yyou can see how git is installing on windows.
Just click next and finally finish the installation.
Linux users could follow this link for the list of commands for installing Git.
Like several cloud hosting services providers, Cloudways offer Pre-installed and ready-to-use Git on all its servers. If you already know how to use Git and want to clone your application on Cloudways, follow this excellent guide on deploying code to your application using Git.
Basic GitHub Commands
Once you have installed Git, the next step is to initialize it . For this, you need to work with Git Bash, SSH or a Windows terminal for working with Git commands. Since I am using a Cloudways server, I will run all commands on the SSH terminal. If you don’t not have a Cloudways server, signup for one now!
To initialize Git, goto the Applications folder and run the following commands.
This command will initialize an empty folder `.git` in the working directory. This folder will keep track of everything happening to the states of the code.
The next step is to add the files of the working directory to the staging environment. You can use the `git add`command for adding either a single file or an entire directory to the staging state. For a single file (for instance, index.php), use the command `git add index.php`. For adding a directory, use the git add . command. It is a good practice to check the status through the `git status` command.
This command will list the files being tracked and are ready to be committed. Running the command will return the list of files that are tracked in the staging environment. Usually, the status command is used to verify that all the files have been added.
Now that the files are being tracked and the code saved in the staging post, the next step is to commit the changes in the file. Commit also highlight the history of changes in the files. Every Commit contains a unique hash code for identification. A sample Commit command is:
git commit -m “My first commit”
In the Commit, everything gets stored. You could always go back to previous Commits, but be careful to switch between the commits. Once the command finishes, run the `git status` and you will see:
This means that the staging environment is now clean and there are no more changes to commit.
Check the history of the Commit through the
git log command. This will give the list of all the commits made during the project. Let’s run the command.
You can identify the Commit with the message or with the long unique hash code. In case of a mistake or a disaster, you could easily revert to a previous Commit. To do this, run the following command:
git checkout <commit hash code>. In this case, the command would be `git checkout cf013cd5f262d5545bdaf9331f25504fbd39b747`
The code will be reverted to that version and previous changes would be dropped. After the command, run the
git log command to check out the Commit history.
There are times when you do not wish to drop the changes in the code. In such cases, use branches to seperate versions of the code. I’ll cover branches deeply in the next article.
Handling File Deletion in the Staging
The biggest fear of any developer is the deletion of a code file by mistake. However, if you use Git, you do not have to worry! You could get the deleted file back by running the following command:
git checkout <deleted file name>. In my case, I first deleted price.php and then used git checkout price.php to get the file back. Now remember that if you really need to delete a file, you must commit the file name to the staging by using the `git commit pricing.php`. If you are deleting the file from Git, you can quickly move it to staging environment without adding it through the following command:
git rm <file name>. In my case, the command will be `git rm pricing.php`.
If you still want the file back, run the command, `git reset HEAD pricing.php`. Your file will be back again.
Push Code to GitHub Repository
Now that you have a good idea of how Git works, it is time to push your committed code to either GitHub or Bitbucket repository. I am partial to GitHub!
For pushing the code, you first need to signup and create a repository on GitHub. Click the New Repository button.
Enter the repository name and description and click Create Repository button.
Your repository is now ready for the code push. However, first, you must add the repository URL to Git. You can find the URL at the top right corner in GitHub.
Copy this URL and run the following command in the SSH:
`git remote add origin https://github.com/shahroznawaz/testdemo.git `
This will add the URL of the GitHub repository to Git.
Now run the git push command by running `git push origin master`. Remember you need to add your username and password of GitHub. Finally, push the code to GitHub.
At this stage, open your GitHub profile and check the repository. You will see the the files in the list.
Cloning GitHub Repository
At this point, the GitHub repository contains the final version of the code. If you need to host this application on a server, you need to clone the repository at that host.
Move to your destination folder where you wish to clone the application and run the following command:
`git clone https://github.com/shahroznawaz/testdemo.git`
This command will make a copy of the original project in the destination folder. Note that I have used the URL of my repository.
Pull the Latest Changes From the Repository
Developers regularly update the repository to make sure that they have the latest version of the code. However, if the application has been cloned elsewhere, there is always a chance that it will be running an outdated version of the application.
To update the application, I need to pull the latest code. For this, first go to the destination folder and run the following command:
This command will fetch the new changes and merge them with the local copy of the code. This GIF by Kevin Skoglund highlights the process:
In essence, when you push code to a GitHub repo, the head of the master branch move to the latest commit and the origin is set to this commit.
In this first installment of Git tutorial for beginners, I discussed the basics of using Git for version control. I highlighted the various commands and then demonstrated how to use a GitHub repo for application deployment. In the next part of this series, I will cover how to manage branches and resolve conflicts deeply so if you need further elaboration of any aspect of this article or would like to contribute to the discussion, do leave a comment below.