Git

 What is Version Control?

When you are working on a simple project, such as a single page html, it is fairly easy to remember the last thing you changed and where the development is headed. But tracking revisions over time, also referred to as version control, quickly becomes more complex when you are working on a large project with multiple files and multiple developers.

You not only want to record changes, but also who made the changes, and when. Managing revisions at this level requires a version control system.

Version Control Systems (VCS) help a software team manage changes to source code over time.

VCS software includes tools for saving the state of a project, viewing the history of changes, and reverting changes.

Developing software without using version control is risky, similar to not having backups.

VCS can also enhance and speed up development. Depending on the version control software used, many developers can work on the same code at the same time.

For example, one developer on the team may be working on a new feature while another developer fixes an unrelated bug, each developer making their changes in several parts of the code base.

VCS even have tools to prevent conflicts when one developer's changes are incompatible with changes made at the same time by another developer.

The Git Version Control System

One of the most popular version control systems is Git, a distributed VCS.

Git is a mature, actively maintained, open source project compatible with many operating systems and IDEs.

Git is different from other version control systems by its way of recording changes. Other systems add changes to a database, where Git records changes as a stream of snapshots.

Git has another advantage - it is distributed.

Rather than having only one single place for the full version history of a project, every developer's working copy of the code is also a repository that can contain the full history of all changes.

Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.

Initializing a Git Repository

The most effective way to run Git is through a command line prompt. That means you'll be using Terminal in Mac/Linux or Command Prompt or PowerShell in Windows.

The first step to start using Git is to initialize a repository, a location for files and their revision history. Of course, this step can only be taken if you've already installed Git on your computer. There are numerous versions and ways to install Git. Which one you use will depend on your environment. Download the version that suits you from the official website.

If you want a repository in a new folder, then you will need to create a new directory (folder) and then switch to that directory. This is done at the command prompt (often indicated with $ or C:>) with the mkdir command for creating a directory and cd for navigating to a directory.

With the commands above, a directory named my_git_project is created in the current folder and then the active directory is changed to my_git_project.

If you want to create the repository in an already existing folder, just navigate to that directory by typing cd directory_name at the command line prompt.

Once inside the appropriate folder, use the git init command to turn the directory into an empty Git repository:

Git vs GitHub

It is important to know the difference between Git and GitHub.

Git is a version control system for managing your source code history.

GitHub is a hosting service for your Git repositories.

Let's create a new repository at GitHub:

1) Go to https://www.github.com and signup/login.

2) Click on the "+" button at top right corner and select "New repository"

To see the files generated by git init, run the following command: $ ls -a

3) Choose a repository name. (You can leave other fields blank for now)

You will be redirected automatically to a page, where you can find all the required information to continue your next steps.

Tracking Files

In general, files in a repository can have the following statuses:

1) Not tracked

2) Staged

3) Committed

To find out the actual status of files in a repository, the git status command is used.

Let's say we have created a file readme.txt in our repository.

Running git status will have the following output:

As you can see the file readme.txt is untracked.

Untracked It means that the file is not being tracked by Git for changes. We should explicitly say which files it should follow/track.

The git add 'file name' command tells Git to track the file. This step is called staging.

Let's add our readme.txt file:

Now write a sample text inside the password.txt and edit the content of .gitignore adding the file name ("password.txt") we want to be ignored.

If you don't want Git to track some specific files, you can "ignore" them.

That is done using the .gitignore file. Anything listed in the .gitignore file is ignored by Git and won't be visible in the repository.

Let's create the .gitignore, as well as a sample password.txt file containing some sensitive data which we don't want to be publicly visible in the repository:

Running git status shows that only the .gitignore file is untracked.

The files listed here are in the Staging Area, and they are not in our repository yet. To add them to the repository, we need to commit them. Check out the next lesson to learn how to commit changes to a Git repository.

Git Commit

The git commit command saves the state of your project by adding snapshots of staged files to the repository.

The git commit can include the -m flag with a message describing what we've changed.

Executing git status after a git commit verifies that tracked files are up to date.

Only changes to staged files (added using the git add command) will be added to the repository with the git commit command.

To commit modifications for every tracked file in the repository, use the git commit -a command:

Unfortunately, this approach does not allow specific comments for each committed file.

If you want to see the history of your commits, use the git log command:

This command inversely lists your commits, their dates, authors, and some other related information about each commit.

After committing the changes, the next step is pushing the local repository to the Git server on a remote location (such as GitHub).

Cloning and Pushing

repository to the Git server on a remote location (such as GitHub or Bitbucket).

After creating a remote repository we have the following options:

1) To download (clone) the repository and start making changes.

2) To initialize a local repository and then connect it with the remote one.

The clone command is used to download a remote repository

$ git clone https://www.github.com/user/project_name.git

If you have already initialized a local repository, you can connect it to the remote one using the following command:

Pushing Remotely

Pushing RemotelyAfter making our local changes and commits, its time to push the changes to the remote repository.

The push command tells Git where to put our commits.

$ git remote add origin 

https://www.github.com/user/project_name.git

$ git push -u origin masterThe name of our remote is origin and the default local branch name is master.

Pulling

A local repository may have commits pushed by other users, who work on the repository. Get the latest updates on the project, especially when you are not the only one working on the project.

We can check for changes on our GitHub repository and pull down any new changes by running:

$ git pull origin master

We can check what is different from our last commit by using the git diff command.

$ git diff HEAD

Reset & Checkout

You can use diff to look at changes within files that have already been staged.

Running git diff --staged will show the changes you just staged.

A stage can also be reset using the reset command:

git reset 'file name'

This removes the file from the staged status, meaning that all the changes will still remain in the file.

To reset the file to the latest committed version, the checkout command can be used:

git checkout -- 'file name'

Branches

Branches are a very important part of git.

Branching allows to make a "copy" of your working project and change it without affecting the main branch (master branch), giving an opportunity to work on the same project with different commits.

When you want to add a new feature or fix a bug - no matter how big or how small - you create a new branch to encapsulate your changes.

After the feature is done, you can merge it with the master branch

Creating a new branch is done using the branch command:

git branch my_new_branch

Now, every change made in the new branch called my_new_branch won't affect the master branch.

This means you can safely work on the project without breaking anything. Each branch has its own history, staging area and working directory.

git checkout my_new_branch

Then we need to switch to the branch using the checkout command:git checkout -b my_new_branch

There is a shortcut to create and switch to a new branch:

Amend

The git commit --amend command is a convenient way to modify the most recent commit.

It lets you combine staged changes with the previous commit instead of creating an entirely new commit.

It can also be used to simply edit the previous commit message:

git commit --amend -m "updated commit message"

Stash

The git stash command temporarily caches any changes you've made to your working copy so you can switch to something else, and then come back and recover them later.

The git stash command takes your uncommitted changes, both staged and unstaged, and saves them for later use.

git stash

After stashing you're free to make any changes, create new commits, switch branches, and perform any other Git operations. Then you can come back and re-apply your stash.

There are two ways to re-load (re-apply) the stashed changes:

pop will remove stashed changes from the stashed state.

git stash apply

apply applies the same stashed changes to multiple branches.

Merging Branches

Let's create and commit a few files on the master branch (main branch). The touch command below will create 5 text files, with names file1.txt, file2.txt, etc.

touch file{1..5}.txt

git add .

git commit -m "add files 1 to 5"

Now let's create and switch to our new branch:

At this point, this branch is an exact copy of the master branch, but every modification, addition, or removal is done in the context of this new "test" branch. Let's add new files and remove a couple of already existing files and then commit the changes.

git checkout -b test

touch file{6..10}.txt

git rm file3.txt

git rm file4.txt

git add .

git commit -m "add new files, remove 3&4"

Now, we have 2 branches, master and test. We are on the test branch which contains some new files and lacks some of the files from the master branch because we removed them. Let's switch to the master branch and finally merge them together.

git checkout master

git merge test

git merge test tells the Git to merge the test branch into the current branch (the master branch in our example).

Merge Conflicts

Let's see what happens if we change the same file in two different branches and try to merge the branches together.

Create file1 with the following text and commit the change:

"This is the original text. We want to explain how merge conflict happens. Follow the instructions and steps correctly."

Now let's create a new branch ("test") and edit file1 by adding the following text after the initial one:

"But we also want to add some text here in the branch 'test'."

Again commit your changes and switch back to the master branch.

Let's see what happens if we change the same file in two different branches and try to merge the branches together.

Create file1 with the following text and commit the change:

"This is the original text. We want to explain how merge conflict happens. Follow the instructions and steps correctly."

Now let's create a new branch ("test") and edit file1 by adding the following text after the initial one:

"But we also want to add some text here in the branch 'test'."

Again commit your changes and switch back to the master branch.

This time add the text below in file1 and commit your changes:

"But we also want to add text here in master's branch file1.txt"

Now, we have file1 with two different variants in two different branches (master and test). Let's merge them and see what will happen.

Because there were two different versions of the file, Git failed to merge them together automatically. We should fix this conflict manually and commit the change.

First of all, let's do a git status. It shows which file resulted to merge conflict (it is useful when you have multiple files). It also suggests how to fix the conflict and commit or abort the merge.

When a merge conflict occurs, Git automatically adds some indicators to make it easy for us to find where the conflict occurs. These indicators are: <<<<<<<, =======, and >>>>>>>.

Usually, the content before the ======= marker is the receiving branch and the part after the marker is the merging branch.

Now, it is your choice to keep only your master branch changes, keep only the test branch changes, or make a brand new change, which may incorporate changes from both branches.

After that, delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge. Save and exit. Finally, commit your changes.

--------------------------------------END OF GIT--------------------------------------------