Git - An Intro
Intro
If you have been in Software development, you will know the importance of Version Control. Version Control 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.
Prior to Git becoming a widely used version control system, there was Mercurial, SubVersion and others. That said, the other systems are still being used by many companies but Git is the most popular.
Before we get into some examples and commands on how to use Git, we will briefly look at some benefits of Git.
-
Long-term change history of every file: This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents.
-
Branching and merging: Having team members work concurrently is a no-brainer, but even individuals working on their own can benefit from the ability to work on independent streams of change.
-
Traceability: Being able to trace each change made to the software and connect it to project management.
How does Git Work?
Understanding how Git works under the hood, or at a higher level will help you in the long run when you develop large-scale projects. Large-scale projects would require developers to write code independently and branching out of the main source code will be required so that individually developed features do not miss out on the larger functionality of the codebase.
Before we move ahead, I am assuming you have either Git bash configured on your system if you are on Windows or if you are on a Unix-based system, git is installed by default in most Unix-based OSs.
Moving on.
At the heart of Git is a git Repository used to contain a project. This repository can be stored locally or on a website such as Bitbucket or Github. The project contains several save points called Commits. The commit history contains all the commits, ie. changes implemented during the development of the project. A Commit allows you to rollback or fast forward code to any commit in the commit history.
The files in each Git project go through several stages:
- Working directory: Modified files, but untracked and not yet ready for commit.
- Staging directory: Adding modified files to the staging environment means they are ready for commit.
-
Committed: Snapshots of files from the staging area are saved in the commit history.
Phase 1 - Staging
If you have made changes to a certain file, you must add it to the staging area if you want Git to track those changes. The staging area represents a layer of security, allowing you to review the changes before committing them. You can run the below command to know which files Git tracks.
git status
To add a file to the staging area, use the following syntax:
git add <filename>
You can make staging faster and stage all files in your working directory by running “git add .” command.
You can also remove a file from the unstaged area using the following command.
git rm --cached <filename>
Phase 2 - Commits
A commit represents a save point for your work, a snapshot of your code at a particular point. Adding files to the staging area means that they are ready to be committed. To check if you have any files ready to be committed, run the following:
git status
The above should show the files that are added to the staging area and ready to be committed. To commit those files, run;
git commit -m <"Notes about the commit">
The <”Notes about the commit”> above can be any comment or notes specific to the files being pushed to the remote repository as it will be easier for reference for other developers and yourselves too.
You can check your commit history by running the below command. The output shows a log of all the commits you have made, who made the commit, the date, and the commit notes.
git log
Phase 3 - Revert
If you want to revert a commit for some reason, git allows you to do that using the below command. You will need the commit ID to revert a commit. The ID can be found using the git log command.
git revert <commit ID>
The other option is to use “git reset” command. However, this permanently reverts back to a certain point and cannot be changed again and has to be re-added. USE THIS WITH CAUTION!
git reset <commit ID>
Forking
A fork is a copy of an existing repository that allows you to make changes without affecting the original project. A forked project can be used to propose changes to an original project that the owner will approve using a Pull Request.
Once a fork is done either on GitHub or Bitbucket, you can run the following command to clone the repository to your local machine.
git clone <URL>
After the clone is completed, you can start working on the repository and make changes to it using the commands and concepts we saw above.
Branching
Branching is a feature in Git that allows you to work on a copy of the original code to develop new features. By this, you do not mess with the main/master branch. This is more like an experimental branch that one can use to work on and if required can be merged with the central code that is present in the main branch. It is recommended to delete the temporary branches once it is merged with the main branch. The syntax to create a new branch in git is as below;
git branch <branch_name>
Merging and Conflicts
The git merge command allows developers working on a new feature on a separate branch to merge their changes with the main branch. What this means is that, let’s say you are working on a branch named “feature1” and you want to merge the changes from this branch to the main branch. Here is what you will run;
git checkout master
git merge <branch_name>
The above will merge changes from “feature1” branch to the master branch. Sometimes, you will across merge conflicts which is a pain for developers, but it’s not if you understand why it is caused. Handling Merge conflicts will need a separate blog in itself, but briefly, what causes merge conflicts is the un-seen changes by you that were made to the master branch by someone else thereby your change not being up to date with the changes. This causes conflict because Git will expect the latest file along with the changes you are making.
Phase 4 - Fetching & Pulling
Fetching & pulling here means getting the latest copy from the Remote Repository to the local folder for you to work on.
git fetch command retrieves from the remote repository and checks for any changes but does not update the local repository, whereas git pull command does both. ie, in short;
git pull = git fetch + git merge
git pull checks for any changes in the remote repository and also updates the local repository with those changes.
Phase 5 - Pushing
git push command pushes your changes from the local repository to the remote repository. The command to run is;
git push
Rebase
Git rebase is a command that allows you to move or combine a sequence of commits to a new base commit. It is often used to clean up a commit history or to integrate changes from one branch into another.
To rebase a branch, you first need to check out the branch that you want to rebase. Then, you can use the git rebase command to move or combine the commits. The git rebase command takes two arguments: the name of the branch that you want to rebase onto, and the name of the branch that you want to rebase. For example, to rebase the feature branch onto the master branch, you would use the following command:
git rebase master feature
This will move the commits on the feature branch to the master branch. If there are any conflicts between the commits on the two branches, Git will stop the rebase and ask you to resolve the conflicts. Once you have resolved the conflicts, you can continue the rebase with the git rebase –continue command. Once the rebase is complete, the feature branch will be updated to include the latest changes from the master branch.
The benefits of Rebasing are, that it can help you to keep your commit history clean and linear & can help you to integrate changes from one branch into another without creating a merge commit.
Commonly used GIT Commands
🔹 𝗴𝗶𝘁 𝗶𝗻𝗶𝘁 -> Create a new git repo in the directory.
🔹 𝗴𝗶𝘁 𝗯𝗿𝗮𝗻𝗰𝗵 -> Create a new local branch.
🔹 𝗴𝗶𝘁 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 -> Switch branches.
🔹 𝗴𝗶𝘁 𝗮𝗱𝗱 -> Add a new file to your staging area.
🔹 𝗴𝗶𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 -> Adds staged changes to your local repository.
🔹 𝗴𝗶𝘁 𝗽𝘂𝗹𝗹 -> pull code from your remote repo to your local directory.
🔹 𝗴𝗶𝘁 𝗽𝘂𝘀𝗵 -> Push local repository changes to your remote repo.
🔹 𝗴𝗶𝘁 𝗽𝘂𝘀𝗵 –set-upstream origin
🔹 𝗴𝗶𝘁 𝘀𝘁𝗮𝘁𝘂𝘀 -> Show which files are being tracked (and untracked).
🔹 𝗴𝗶𝘁 𝗱𝗶𝗳𝗳 -> See the actual difference in code between your Working Directory and your Staging Area.
The git command list is huge and the above is just the commonly used commands. Although it is possible to develop software without using any version control, doing so subjects the project to a huge risk. So the question is not whether to use version control but which version control system to use.