A version control system is a tool that lets you track the history and attribution of your project files over time (stored in a repository), and which helps the developers in the team to work together. Git is one of the most popular version control systems. Multiple projects files are maintained in a Git repositories such as GitHub, GitLab, and Bitbucket to facilitate software development projects sharing and collaboration. You can track changes, revert to previous stages, and branch to create many versions of files and directories.
Setting up Environment
Before walking through into mostly used git commands, you have to setup user to track changes effectively.
Setting User-name & Email
You should configure user information globally for all local repositories. Set the name and Email you want attached to your commit transactions.
$ git config --global user.name [name] $ git config --global user.email [email address]
Setting default editor
By default, Git uses the system default editor but you can change the default editor by following command:
$ git config --global core.editor vim
Setting Default Merge tool
Git does not provide a default merge tool for integrating conflicting changes into your working tree. You can set default merge tool by enabling following settings.
$ git config --global merge.tool vimdiff
Listing Git settings
To verify your Git settings of the local repository, use git config –list command as given below.
$ git config --list
The Above command with print the below output.
user.name=your-name [email protected] push.default=nothing branch.autosetuprebase=always color.ui=true color.status=auto color.branch=auto core.editor=vim merge.tool=vimdiff
Creating a Bare(Server) Repository
Git init initializes a brand new Git repository and begins tracking an existing directory. It adds a hidden subfolder within the existing directory that houses the internal data structure required for version control. To create a new repository specifically for collaborating on a project, to share work with all the team use below command:
$ mkdir server_repo $ cd server_repo $ git init --bare practice.git #output Initialized empty Git repository in /home/user-name/server_repo/practice.git
Cloning a Git Repository
Git clone creates a local copy of any project that already exists remotely. The clone includes all the project’s files, history, and branches. Provide a password to the
$ mkdir client_repo $ cd client_repo $ git clone [email protected]_ip:server_repo/practice.git #output Cloning into 'server_repo'... [email protected]'s password: warning: You appear to have cloned an empty repository.
Git add stages a change. Git tracks changes to a developer’s codebase, but it’s necessary to stage and take a snapshot of the changes to include them in the project’s history. This command performs staging, the first part of that two-step process. Any changes that are staged will become a part of the next snapshot and a part of the project’s history. Staging and committing separately gives developers complete control over the history of their project without changing how they code and work.
Create a file or make changes in existing files
Let’s create a file and we will add this file to repository
$ touch hello.txt (or) $ vim hello.txt $ git status #output On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) hello.txt nothing added to commit but untracked files present (use "git add" to track)
Stage the file
Next, let’s add file to the staging area. Git status shows the status of changes as untracked, modified, or staged.
$ git add hello.txt $ git status #output On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: hello.txt
Commit the file
git commit saves the snapshot to the project history and completes the change-tracking process. In short, a commit functions like taking a photo. Anything that’s been staged with git add will become a part of the snapshot with git commit.
$ git commit hello.txt –m "committing hello.txt" #output On branch master Your branch is based on 'origin/master', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working tree clean
After finish working on the initial version of the project, it is ready to be published. You can publish the changes using git push command.
Push the file to Remote Repository
git push updates the remote repository with any commits made locally to a branch.
$ git push #output Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 208 bytes | 41.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To 192.168.72.128:server_repo * [new branch] master -> master #If you want to push the code to the master branch $ git push origin master #output Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 220 bytes | 73.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To 192.168.72.128:ravi_repo/practice.git * [new branch] master -> master
Pull files from Remote Repository
git pull updates the local line of development with updates from its remote counterpart. Developers use this command if a teammate has made commits to a branch on a remote, and they would like to reflect those changes in their local environment.
$ git pull <remote> <branch>
Examining history and Viewing changes
Since you have committed the code to the remote master branch, you can see the status then use git log command:
$ git log #output commit d121916e6e5021b9d48490533bde2eb4dd76d4ec (HEAD -> master, origin/master) Author: Ravi <[email protected]> Date: Thu Sep 24 00:45:19 2020 -0400 committing to server_repo
You can get the changes over the time for a specific file by following command.
$ git log -p <file>
You can get the information about who changed what file over the time for a specific file by following command.
$ git blame <file>
Hence you get better understanding of git commands that are widely used in practical world.
Read Also : How to Install and Setup Git on Windows