Introduction to GIT

We can do a lot with git, before trying anything on PROD machines make sure to play with git on your local machine or test machine.

Prerequisites
=> Install git.
=> Be familiar a bit with the command line.
=> Play with the repository.

Install git
=> yum install git -y

Configure user/email
=> git config --global user.name "Sunny Bhambhani"
=> git config --global user.email "bhambhani147@gmail.com"
=> git config -l

user.name=Sunny Bhambhani user.email=bhambhani147@gmail.com

Initializing a new git repo
=> pwd

/root/git-test

=> git init

Initialized empty Git repository in /root/git-test/.git/

A new hidden directory called .git will now be present in your project directory. This is where Git stores its database and configuration information so that it can track your project.

Cloning a repository
=> pwd
/root
=> git clone https://github.com/bhambhani147/TT-Help.git

Cloning into 'TT-Help'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done.

Cloning is a way to access shares repository. Similar to checking out a repository in other systems, running git clone <repository URL> will pull in a complete copy of the remote repository to your local system. Now you can work away on it, making changes, staging them, committing them, and pushing the changes back.

Adding a New File
=> pwd

/root/TT-Help

Now lets create a new file, lets say it doc01, in our project directory /root/TT-Help. After saving the file, from the terminal run the command git status. This will show you the current status of your working repository. This will show all the untracked files.

=> git status

# On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # doc01 nothing added to commit but untracked files present (use "git add" to track)

Just for playing around lets create a new file in the same directory. We will try to work without having to commit all of them. Lets call it doc02, add some text in it and run git status again, and now there are two files listed as untracked.
=> git status

# On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # doc01 # doc02 nothing added to commit but untracked files present (use "git add" to track)

Now let’s stage doc01, because we’re not interested in doc02 just for the moment. To do that, run git add doc01. Now run git status again, and you’ll see doc01 listed as a new file under “Changes to be committed,” and doc02 left in the “Untracked files” area.

=> git add doc01
=> git status

# On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: doc01 # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # doc02

Making the first commit
Committing means you are now ready to push your changes to the git repository. Start the process add a meaningful commit message to explain why the change was made, and that’s it, the file’s changed. So run git commit. This will automatically open up your editor and display the commit template below.

=> git commit

My first commit #MESSAGE # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: doc01 # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # doc02

Once you save the file you will see a message with a hash.

[master 78ecff4] My first commit 1 file changed, 5 insertions(+) create mode 100644 doc01

OR

You can do all of this with a single command.
=> git commit doc01 -m "My first commit"

The output of git status helps to see the state of our working repository, which makes it easy to remember on what we’re committing and what we’re not.

Seeing the differences
Now to know how to review file changes? To review changes in a file, we use the command git diff command. It compares two files and shows the changes the more recent file contains, if any. Before each line you see a plus sign, which indicates an addition. So all of those lines are being added to the file. If we’d removed any content, it would be preceded by a minus.

diff --git a/doc01 b/doc01 index 8320b2d..b6dba59 100644 --- a/doc01 +++ b/doc01 @@ -2,4 +2,4 @@ 2. Execute XYZ 3. Follow the process. 4. Save the changes. -5. Exit +5. Exit....

Viewing Change History
Now, what if we wanted to see our repository or file history over time? To do that, we need to use git log. Just running git log in our project repository will show a list of changes in reverse chronological order. With no further arguments, you’ll see the commit hash, the author name and email, a timestamp for the commit, and the commit message.

=> git log

commit c48e01b0b6370130dc0abedc48231b5ecf0d0a69 Author: Sunny Bhambhani <bhambhani147@gmail.com> Date: Tue Oct 17 05:11:10 2017 +0000 doc02 commit f8b172d4cd2427c9ead11ffda5167bc3b80451a7 Author: Sunny Bhambhani <bhambhani147@gmail.com> Date: Tue Oct 17 05:03:48 2017 +0000 Second Commit

Want to see just the commit hash?
=> git log --oneline

c48e01b doc02 f8b172d Second Commit 78ecff4 My first commit 3ce0ead Initial commit

Branching
This is one of the fundamental aspects of working with Git. If we work at the main trunk i.e. the master then possibility the problems can arise quickly when more than one person works on the same section of the same file. Branches are essential for being able to safely experiment with concepts and ideas. Git makes it painless to create your own branch, experiment with or implement features, and then merge those changes back into the development branch.

Till now we were using the master branch, which is what Git starts with by default. Now we’ll create a dev branch. From your terminal, run git checkout -b dev to create a new branch called dev. Running this command will both create and check out the new branch, which at first is simply a copy of the master branch.

=> git checkout -b dev

Switched to a new branch 'dev'

Now let's say you have made some changes in dev branch have staged the changes as well as committed the changes but when you check out the master branch those changes will be lost because those changes are in the dev branch. So to bring them on the same page we need to merge them to the master branch. First, we need to check out the branch we want to merge. To do that, run git checkout master. Then we need to merge the changes to the current branch from the branch we’ve worked on. To do that, run git merge dev.

=> git add doc03
=> git commit -m "doc03 from dev"

[dev 3d69147] doc03 from dev 1 file changed, 1 insertion(+) create mode 100644 doc03

=> git status

# On branch dev nothing to commit, working directory clean

=> git checkout master

Switched to branch 'master' Your branch is ahead of 'origin/master' by 4 commits. (use "git push" to publish your local commits)

=> git merge dev

Updating 78230e0..3d69147 Fast-forward doc03 | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc03

Still, we can do a lot with git, before trying anything on PROD machines make sure to play with git on your local machine or test machine.