2. Introduction

Download Link: https://git-scm.com/downloads

A version control is a kind of system which allows you to keep track of the changes that have been made to a code over a duration of time. This means that you can, at any given point in time, revert back to the older versions of the code you are working on.

Git is a popular VC software. Git works on Distributed Version Control Systems. This system provides everyone the copy of all files and allows user to edit them locally. The user can then work on the files locally and then upload the files to the server. The advantage of DVCS is that, if a server crashes, a local user can upload the files and make it running as they have a complete copy of the server data.

../../_images/git_distributed_model1.png

Fig. 2.12 Distributed Version Control System. (ref: Git Book V2)

Git stores the content in form of trees and blobs. A blob (or Binary Large Object) is a object type used to store file content. It doesn’t store metadata like date of creation of file. A commuted checksum SHA-1 is used to represent the file. A tree holds the listing of other trees and blobs. A commit takes the snapshot of the tree at that specific moment and saves it. When you create another commit, a new snapshot is taken with only the required changes in the new commit. The old / unchanged file remain the same and the new commit points to the old files. Thus the storage required is only for changed files.

../../_images/git_objects_1.png

Fig. 2.13 GIT objects (ref: Git Book V2)

3. Workflow

In a git, you have Working Directory, Staging Area (index), .git Directory (local repository), Upstream Directory (remote repository), and Stash.

Elementary Git workflow (You already have a git initialized repository):

  • You modify a file in your Working Directory

  • You mark the edited files are confirmed changes and stage them. This saves only the changes as a snapshot. The original file is stored as a reference.

  • You commit those files. This takes the staged files and stores the snapshot of changes permanently in your git repository.

  • You Push your changes from local repository to remote repository

../../_images/git_states.png

Fig. 3.14 Git States (ref: Git Book V2)

Small Teams

When you are working in a small team say 2 members, then your workflow will be like in image below.

The typical activities done are:

  1. Creation of a new repository either online or local on PC.

  2. Clone repository if created online. Push repository to server if created offline.

  3. Create required branch (say feature)

  4. Code and Test it.

  5. Commit the code.

  6. Repeat steps 4 and 5 till a certain part of feature is ready.

  7. Push to remote repository.

  8. Repeat steps 4 to 7 till the feature is completed.

  9. Merge the feature branch into main branch.

../../_images/small_team_flow.png

Fig. 3.15 Git workflow small team (ref: Git Book V2)

Contributing to online projects

When you are contributing to online repositories, the following activities are typically performed (ref: Git Book V2):

  1. Fork the project to your account.

  2. Create a topic branch from master.

  3. Make some commits to improve the project.

  4. Push the codes to your account’s project.

  5. Open a Pull Request on platform (say GitLab).

  6. Discuss with the project’s team, and optionally continue committing.

  7. The project owner merges or closes the Pull Request.

  8. Sync the updated master back to your forked project.

4. Commits

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the authors name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit and multiple parents for a commit that results from a merge of two or more branches. (ref: Git Book V2)

There is no certain rule for commits but is suggested to be like ONE commit per ONE task / bug.

The commit messages are important as they provide info about what you edited in that specific commit. Thus when you review your changes history, you can recollect what you did by reading the message or when a 3rd person is going through your work can make a sensible understanding of your changes if they plan to work on your repository. The suggested length of text is of 50 characters. You provide to the point info in this.

Ex, if you change a function in a code:

  • Fixing file in code // Not good

  • Fix function ### // Good

  • Fix function ### in file ### // Better

Hint

The files which are not required to be tracked can be ignored during commit using .gitignore file (found usually at root directory). Usual untracked files may include build files or temporary files. To untrack a file simply add the relative location of the file / folder to the .gitignore file.

Hint

If you forgot some files in the last commit or want to update your commit message, you can add the files to the staged area and the use amend command. You must do this before you push to remote repository.

5. Git Branches

It is used to create a separate directory of your code and then work on that copy. This allows you to create a copy from your main working branch with all the history of changes in it. You can then work on the new branch so as to fix a bug or implement a new feature. Once done, you can merge the branch to your main branch.

This helps in avoiding to edit files on a working environment. Ex, you have a blink LED program which starts automatically when the board boots up. You need to implement a button trigger to start this blink. So, you create a new branch from your main, and then implement and test your code. When everything works, you combine the changes from new branch to main branch.

You can also work on multiple branches simultaneously and can fix a bug while you are working on a new feature. Just be sure when merging your new features, you en-corporate the bugs fixed on the main branch during the development of the new branch.

6. Merging and Merge conflicts

To incorporate the new branch into the main branch, you use merge command. This copies the required code from the source branch to the target branch. The source branch can then be deleted if required.

In a situation if two people A & B are working on same project. A updates README.md file and pushed the changes. B also adds content to README.md and pushes the changes. But B gets a conflict error as B did not pull the A’s updated version of README.md rather just pushed the changes.

../../_images/git_conflict.png

Fig. 6.26 Git conflicts demo.

To avoid such conflicts:

  • Always PULL before PUSH.

  • Do not have more that one developer working on a specific file.

  • Try merging main branch frequently to your feature branch to keep new changes updated in your feature branch.

7. Tags

To mark a specific milestone for the project, tags are used. Tags are initially saved on local repository and have to be pushed to remote.

There are two types of tags (ref: Git Book V2):

  • Lightweight: It points to a specific commit.

  • Annotated: It stores the data as full object in git database. It contains tagger name, email and date.

The tag type depends on what information you want to save. If its a temporary tag, Lightweight is better option.

Hint

You can use semantic versioning for creating tags. Can find more information here: ( https://semver.org/ )

../../_images/semantic_versioning.png

Fig. 7.6 Semantic Versioning (ref: Semantic Versioning Wikipedia)

8. Rebase

This allows to move commits and its history to another branch. This means that you are changing the base of your branch and making it appear as if it was created from a different commit. The main use of rebasing is to have a linear commit history.

The difference between a merge and rebase is that, in merge, if the branch moves forward with a commit, merge will create an empty commit. Hence it will be stored in your history.

In rebase, git finds a common commit and saves the differences after that. Then in sequential order applies the changes.

../../_images/basic_rebase_1.png

Fig. 8.17 Repository with difference in branches

../../_images/basic_rebase_2.png

Fig. 8.18 Merge command

../../_images/basic_rebase_3.png

Fig. 8.19 Process of rebase

../../_images/basic_rebase_4.png

Fig. 8.20 Final repository history after rebase

Hint

For more information about this, visit

9. Git Interface

Git is officially available as a command line tool, but is also available in different environments. You can download git command line tool from ( https://git-scm.com/downloads ). There are various GUI tools and extensions for popular IDE / Code Editors available.

Initially you need to provide some details about you when you first install git. To do so, open a new terminal / cmd.

For windows users -> Enter git config --global core.editor “notepad” in it.

Enter git config --global --edit in it. A file will open in text editor. Enter your name and email in that after colon (:).

10. Git Commands

A basic list of commands used in git is provided below. For additional commands, please refer the ( https://training.github.com/ )

Clone new repository:

  • git clone -b <BRANCH_NAME> <REPOSITORY_URL_WITH_HTTPS>: To download repository to your PC as local repository.

Basic Workflow:

  • git status: This provides you the current status of your repository. Ex, info about files modified, last commit info, branch info etc.

  • git add PATH_TO_FILE or git add . : It adds the files to staging area. The dot (.) adds all changed files inside your working directory to your staging area.

  • git commit -m “commit message”: It moves the files from staging area to local repository. The -m is a required flag. It is used to provide a sensible commit message to name the changes you did. Ex. Fix blink function in blink.cpp

  • git push: Publishes the changes from local repository to remote repository.

Make new branch from main:

  • git checkout main: To set main branch as default work branch.

  • git pull: To download changes from main branch.

  • git branch NEW_BRANCH: Create new branch

  • git checkout NEW_BRANCH: Select NEW_BRANCH as default work branch

  • git push --set-upstream origin NEW_BRANCH: To set NEW_BRANCH as default when uploading to remote repository.

Tags:

  • git tag: List current tags.

  • git tag -a [Name_for_Tag] [Commit_Hash_ID]: Add a tag with specific name for a specific commit.

  • git push –tags: To push tags to remote.

  • git push –follow-tags: Push only annotated tags to remote.

  • git show [TAG_Name]: Display details of tag.

  • git tag -d [Name_for_Tag]: TO delete a specific tag. To remove it from remote repository, use git push origin :[Name_for_Tag]

Amend:

  • git commit –amend: Adds the files to our last commit.

Log:

  • git log: To see the complete history of git commits.

  • q / z: to exit the log.