The Beginner’s Guide to Learn the Basics of Git
Introduction
Git is currently the most popular implementation of a distributed version control system for managing source code. Version Control is a system for tracking all the changes to files. As you modify files, the version control system records and saves each change. This allows you to restore a previous version of your code at any time on the git repository.
The core of Git was originally written in the programming language C, as Git is open-sourced so anyone can re-implement in their own preferable language, like the same way it is re-implemented in other languages, e.g., Java, Ruby, and Python.
From Git version 0.99, latest Git version 2.21. A version control system like Git makes our code easy to:
- Keep the whole track of each code and its committed history of the repository.
- Work together as a team from the remote place as well, which makes code repository available at the commonplace.
- Take care as who made which changes and when for which file, each activity is saved.
- Easy to deploy to staging or production server.
We can say Git stores all this information in a data structure called a Git repository. The repository is the core of Git. To be very clear, a Git repository is the directory where all of your project files and the related metadata resides.
Take a look at git workflow shows below, how changes are saved from working directory to remote repository
Working directory — The working directory contains the set of working files for the repository. You can change and modify the content whenever you want and commit the changes to the repository. Every new commit is going to save in binary format so that the same name of files committed by others will also be saved with another unique binary file name.
Staging area — The staging area is the place to store changes in the working tree before the commit. It’s the middle stage which contains a snapshot of the changes in the working directory for changed or new changes that are relevant to create the next commit and stores their mode like filetype etc.
Repository — A repository contains the history, the different versions over time and all different branches and tags. In Git each copy of the repository is a complete repository.
Now we talk about operations that work with the Git repositories. Below git architecture helps to understand more about git workflow.
Working with Git Commands
Now that you understand how to create a git repository, you’ll need to know how to save file changes. It is important to note that Git does not automatically save every change you make. You must tell Git which changes you want to be recorded by staging those changes. After staging, you can commit the changes so that they are recorded in the repository.
Create a git repository
There are two ways to create a local repository on your machine. Either you can create a new repository from scratch using a file folder on your computer or clone an existing repository from Github using git clone command.
git init — create a new repository from scratch. It can be used to introduce Git into an existing, unversioned project in order to start tracking changes for that folder.
Note: using command prompt go to the required directory path and initialize using git init.
$ git init
Initialized empty Git repository in /TestRepo/project1/.git/
git clone — git clone command to copy a remote repository onto your local machine. By default, git clone automatically sets up a local master branch that tracks the remote master branch it was cloned from.
Note: using command prompt go to the required directory path and run the command.
$git clone <url of git repository>
Create a branch
When for the first time the git project is initialized. It is suggested to keep master branch separated from all others branches on the repository, means branch can be created for every new version or new changes named so existing changes were not override with new ones.
git checkout -b <branch_name>
After creating a branch can switch directly to branch using:
git checkout <branch_name>
3. Make changes to the repository
Changes made in the working directory will not be saved directly to the repository. All changes must first be staged in the index in order to be saved in the repository. Only the files in the index are committed to the repository. Also for changes made we can check with git status, to get the idea for what needs to add on the remote repository.
git status — Before adding the file to remote repository check status made using git status in that local changes in red when you type git status. These changes may be new, modified, or deleted files/folders.
git add — Use git add to stage local file/folder for committing.
git add <folderName or fileName>
To add and commit all local changes in one command:
git add .
git commit — The git commit command enables you to record file changes in the repository’s Git history. By committing, you will be able to view all changes chronologically in the respective file or directory.
git commit -m “<commit message relevant to changes done for files.>”
4. Syncing remote repository with new changes
Remote repositories allow sharing our changes with others having the same repository. They can be on a private server, on a different computer than yours. Wherever yours is hosted, you’ll need to be able to synchronize your local repository with the remote repository. You’ll do this using three commands: git push, git pull, and git merge.
git push — In order to start sharing changes with others, you have to push them to a remote repository using the “git push” command. This will cause the remote repository to update and synchronize with your local repository.
Before running push command checkout to branch from where you want to push changes, using git checkout command.
git checkout <branch_name>
And all changes made should be committed and working directory needs to be clean when the code is going to push on another branch from the local branch.
Note: It’s good practice to check before pushing code to another branch, take a pull from that branch if it is having others change on a remote repository and then push your changes.
git push origin <branch_name>
git pull — Whenever somebody pushes their changes to the shared remote repository, your local repository becomes out of date. To re-synchronize, your local repository with the newly updated remote repository, run the “git pull” operation.
git pull origin <branch-name>
When the pull is executed, the latest revision history will download from the remote repository and import to your local repository.
git merge — Your push to the remote repository will be rejected if your local repository is out of date, possibly because there are some updates on the remote repository that you do not have locally yet
If that is the case, you’ll have to use the git merge command to grab the latest change from the remote repository before you are allowed to push. Git enforces this to ensure that changes made by other members get retained in history.
Remember — During a “merge”, Git will attempt to automatically apply those history changes and merge them with the current branch. However, if there is a conflict in changes, Git will throw an error prompting you to resolve the conflict manually before making changes to it.
Resolve merge conflicts
When merging two branches, you may come across a conflict that needs resolving before you can properly complete the merge. For example, when two or more members make changes on the same line of a file in the two different branches (remote and local branches in this case), Git will not be able to automatically merge them.
When this happens, Git will add some standard conflict-resolution markers to the conflicting file. The markers help you figure out which sections of the file need to be manually resolved.
In our example, everything above “=====” till “<<<<<<< “ is your local content, and everything below it till “>>>>>>” comes from the remote branch.
Handy Tricks :
git log — To print out all the commits which have been done up until now and gives the list of pushed commit logs record that helps to check current commits log till date time, before pushing newly committed changes our changes.
The log shows the author of each commit, the date of the commit, and the commit message.
git diff <filename> — the list changes done in that file if any in green color lines and deleted lines of code in red lines if any.
Resources : 1.https://www.vogella.com/tutorials/Git/article.html#analyzechanges_in_githistory
2.https://backlog.com/git-tutorial/rewriting-history/
3.https://github.com/joshnh/Git-Commands
4.https://en.wikipedia.org/wiki/Git
