Basics Of Git

Git is the most popular distributed version control system which is commonly used by developers. It enables several users to work on a document concurrently and keep a record of the changes made and various versions of the documents in a project.

What is Git?

Git is a DVCS that was coded to enable developers to follow the progression of their projects. It allows different developers to contribute to the same source code, same with the files it allows the tracking of the changes of those files and assists in solving the conflict in case two different file versions were edited. Git remains special because it stores revisions allowing the usage of different versions, contribution to code, and general software development processes.

History and Evolution of Git

Git was started in 2005 by Linus Torvalds who is well known for developing Linux kernel. Originally it was developed to address such a simple but important need as the requirement for a fast, reliable, and decentralized distributed version control system. Prior to Git, the development team of Linux kernel used another version control system called BitKeeper which is a commercial software.

When the free use of BitKeeper was taken away, Linux was in search of a similar open-source SCM and Torvalds developed Git. Git soon enough became famous for how fast it was, how strong it was, and how it was capable of handling other models of development which include the branch and merge models. Since then, it has grown into one of the most used version control tools in the software industry.

Importance of Version Control Systems

Version control systems such as Git/ SVN are very vital in contemporary software development. It enables tracking of changes by time, coordination of the project and maintaining good quality of the code.

Some of the key benefits of using Git include:

• Collaboration: Git allows working on a single project by many developers at a time without interfering with each other’s work.
• Version Tracking: Compared to other similar programs, it is fully documented which makes it convenient when working on change management as all changes are indicated and more information about what was changed, when and who it was done is provided.
• Backup and Recovery: In case something is wrong, then Git enables the developers to go back a couple of versions or a single line of code in the project, which reduces the likelihood of data loss.
• Branching and Merging: The branching feature of Git which is very advantageous to different developers enables one to work on new features or new branches of a program without necessarily correcting a bug without affecting the other programmers and to merge the branches when they are ready.

Getting Started with Git

1. Setting Up Git for the First Time

However, as a first step, Git has to be installed on the computer to be used. It can be obtained from Git’s Official site and you have to follow the instructions on how to install Git.

2. Configuring User Information (Username, Email)

Once installed, you need to configure your username and email for Git:

git config --global user.name "Your Name"
git config --global user.email "youremail@example.com"

Core Concepts of Git

Repositories: Local vs. Remote

• Local Repository: This is the type of project that is saved in the computer that you are using in the course of a particular project. It has the complete log history of all the commits that have been made along with branches made and tags created. Whenever you modify your project and make a commit on it then all those changes are stored in the local repository. What is more, because Git is distributed, every developer has his or her own local repository including all the project history, so one can easily work on it offline and share updates when necessary.
• Remote Repository: Remote repository is contained in a server and is usually multi-accessed by other individuals. Remote repositories are hosted on common platforms such as GitHub, GitLab, or Bitbucket and so on. These platforms enable collaboration of the teams involved in the project and in this case multiple developers can come up with codes and push changes or even manage issues. They are able to commit changes to the local repository and pull changes from the remote repository in order to ensure that everybody is working with the most up to date version of the code.

Working Directory, Staging Area, and Git Repository

• Working Directory: Working directory is the directory that the user usually operates and manipulates to run files of the project. It comprises all the files and the folders that are in use at the current time. Learn that change or creation of files occur in the working directory when using the put, write and remove commands. These changes are noticed by Git but they are not recorded until the staging or the committing is done.
• Staging Area (Index): The staging area is the area that you can work through changes that you are preparing for the next commit. With the git add command, you made a specification to Git on what changes should be committed in the next commit. This means that you can choose which modifications should go into the commit and which should not, which gives you a good deal of control over what you’re tracking.
• Git Repository: This is the database where Git stores all the history of your project starting from the commits, branches and all the references. Identically to the commits related to your project, the repository has all the snapshots of your project in the state it was every time you made a commit. It serves as the central repository of records for your particular project or its progress.

Understanding Commits

A commit in Git is the granularity of change in Git. A commit then can be described as a record on a particular state of the project at a given time in the development cycle. Every commit has information of what has been changed, who did the change, and when the change was made.

Basic Git Commands

Initializing a Repository: Creates a new Git repository in the current directory.

git init

Cloning a Repository: Downloads a remote repository to your local machine.

git clone <repository_url>

Checking Repository Status: Shows the status of your working directory and staging area

git status

Adding Files to the Staging Area: Stages files that we want to commit next,the files that are to be included in the next commit are added to the staging area.

git add <file_name>

Committing Changes: Stores the changes that have made in the staging area to the repository.

git commit -m “Commit message”

Viewing Commit History: It gives history of commits in the given repository.

git log

Branching and Merging

What are Branches?

Branches in Git are one of the core functionalities that help the developers to progress upon multiple versions of a project at the same time but not affecting the main code. A branch can be described as a light-weighted reference to a specific commit in the repository this makes it possible to create workbenches that can be used for developing, testing, as well as experimenting on new features, bug fixes, or the other change(s) that may be required separately from the mainstream project.

Creating and Switching Branches:

git branch <branch_name>   # Create a branch
git checkout <branch_name> # Switch to a branch (old method)
git switch <branch_name>   # Switch to a branch (newer method)

Merging Branches: Merges the changes of another branch with your branch.

git merge <branch_name>

Understanding Merge Conflicts and Resolving Them

When Git cannot merge changes for one reason or another, there are clashes or as they are commonly referred to as merge conflicts. These conflicts have to be resolved manually where one has to go ahead and edit the files that have been affected.

Working with Remotes

Adding Remote Repositories: To add the git remote named as origin, use the following command:

 git remote add origin <repository_url>

Connects your local repository to another remote repository.

Fetching Changes from Remotes: The first step is to retrieve the latest files from the server using the command git fetch.

git fetch

Updates downloads from a remote repository without integrating them.

Pulling Changes: Fetches and merges changes from a remote repository.

git pull

Pushing Changes: Transmits your changes from a local working copy to a remote repository.

git push origin <branch_name>

Undoing Changes

Undoing Staged Changes: This command helps to unstage files and therefore they are no longer recognized by Git.

git reset <file_name>

Undoing Committed Changes: git revert, git reset — hard

• git revert: Creates a new commit that undoes a previous commit.
• git reset --hard: This one is used to delete a commit from git commit history.

Removing Files from the Staging Area: Deletes a file and stages the removal.

git rm <file_name>

Stashing Changes

Stashing in Git is a useful functionality which allows the developers put a set of changes that cannot be committed at the moment yet and exclude them from the working tree. This is particularly helpful if at the end of, say, a shift (for example, between branches), one doesn’t necessarily wish to commit partial changes.

Stashing in other words is the act of storing the current working directory and the index folder in a stack thus allowing you to delete your working directory clear it and go work at something different before you can come back to the previous changes.

Stashing Changes:

git stash

Applying Stashed Changes: git stash apply, git stash pop

git stash apply   # Apply without removing from stash
git stash pop     # Apply and remove from stash

Managing Stashes: git stash list, git stash drop

git stash list    # Shows all stashed changes
git stash drop    # Deletes a stash

Managing Stashes: git stash list, git stash drop

git stash list    # Shows all stashed changes
git stash drop    # Deletes a stash

Understanding Git Tags

The tags in Git are the tools that allow marking some particular line or some point in the commit history as remarkable. Usually, tags are utilized to define the release (for instance v1.0,v2.1.3). Branches in Git are rewriteable, that is, they can be moved around while tags are rewriteless, meaning once a tag has been set, then it can only point to one commit and will forever point at that commit. To label commit for a release version, tags are employed which makes it easier at a later stage to refer to a particular commit.

Creating and Managing Tags: git tag

git tag v1.0      # Create a lightweight tag
git tag -a v1.0   # Create an annotated tag

Annotated vs Lightweight Tags

• Lightweight Tags: These ones are just pointing to a certain commit. A Lightweight tag is exactly a pointer which points a specific commit as well as there is no message and obviously no date linked with it. Commit description is actually just a string, it’s essentially just the word commit with ‘description’ appended to it.
• Annotated Tags: It is used for storing other information such as a tag message, the name of the person who tagged and the date at which the tag was made. Annotations are also saved as full objects within the Git database and give extra info about the tag and the purpose they serve. These are mostly used to tag the release versions.

Pushing Tags to Remote

git push origin <tag_name>

Viewing and Comparing Changes

Viewing Differences Between Commits: Compares the difference of two commits.

git diff <commit1> <commit2>

Comparing Branches and Files: Concerned with comparing the changes observed in the two branches.

git diff <branch1> <branch2>

Viewing Commit History Graphically: Tells the commit history in a concise way, and in a form of a graph.

git log --graph --oneline --all

Collaboration with Git

Forking and Pull Requests

• Forking: The method of copying the original repository under your own account for the purpose of personal work.
• Pull Requests: A way to prompt the owner of the original repository to come and review the changes that you have made and even integrate them into his/her branch.

Code Reviews and Merging PRs

Code reviewing through pull request to avoid poor code input and to allow discussion prior to integrating code in the master branch.

Best Practices for Collaboration

• Provide descriptions in the commit to enable one to understand the kind of change made.
• Push changes often so that there are no merged changes conflicts.
• There will be a case that one has to pull from the remote repository to keep up to date frequently.

Git Workflows

• Centralized Workflow: Everything is trunk, or main for those projects which are recent, commit directly to the branch chosen by the developers, commonly it is the main.
• Feature Branch Workflow: Every single new feature is created in a different branch and the branches are merged only when all the changes are done and checked.
• Gitflow Workflow: A structural process containing branches for feature, for releases, and for hotfixes and using a strict versioning scheme.
• Forking Workflow: Users clone the top level repository, modify the code and push to that repository in the form of pull requests.

Advanced Git Concepts

Rebase vs. Merge

• Rebase: Replays commit history by applying the changes from one branch on another proceeding from the assumption that the second branch is the other side of the first one. This create linear history thus making it easy to comprehend. However, rebase should be used wisely and in conditions when there are several contributors working in the same branch.
• Merge: Integrates modifications done to one branch with another branch without altering its version history. This method retains the history of all the commits made but may lead to large commit trees with merge commit status.
• When to use: Rebase is recommended when you have made changes to the source code and a dirty history needs to be cleared before merging with the main branch while merge is recommended if the developers want to keep a record of all the changes made during the development line.

Cherry-picking Commits

git cherry-pick <commit_hash>

above command is a way more specific than merging and consists in modifying a branch by applying some commit of another one. This comes in handy where one wants to implement change while avoiding the creation of unnecessary additional work.

Squashing Commits

git rebase -i

• Based on the git rebase -i, it allows to combine several commits into one and make the history of commits more condensed. Squashing takes place before merging a feature branch into main with a purpose of presenting the work as a single set of changes.
• When to use: The first case to which one should commit is when there are multiple small and incremental changes that have to be committed, but do not need to be retained in the commit history.

Submodules in Git

• Submodules are used for managing one git repository within another git repository. That is especially helpful when it comes to handling inter-project dependencies. Submodules are used to maintain a link to a particular commit from fresh external repository so a dependency doesn’t change from version to version of a project.
• When to use: Submodules come in handy where a project you are working on relies on other code repositories that have to be managed separately from the main project.

G

gmoksi039

Follow

Improve

Article Tags :

• Web Technologies
• Git