Chapter 03
Chapter 03
Version Control: GIT Features, 3-Tree Architecture, GIT –Clone /Commit / Push, GIT
Hub Projects, GITHub Management, GIT Rebase & Merge, GIT
Stash, Reset, Checkout, GIT Clone, Fetch, Pull, Membership GITHUB.
Version control, also known as source control, is the practice of tracking and managing
changes to software code. Version control systems are software tools that help software teams
manage changes to source code over time. As development environments have accelerated,
version control systems help software teams work faster and smarter. They are especially
useful for DevOps teams since they help them to reduce development time and increase
successful deployments.
Version control software keeps track of every modification to the code in a special kind of
database. If a mistake is made, developers can turn back the clock and compare earlier
versions of the code to help fix the mistake while minimising disruption to all team members.
Git is a DevOps tool used for source code management. It is a free and open-source version
control system used to handle small to very large projects efficiently. Git is used to track
changes in the source code, enabling multiple developers to work together on non-linear
development. Linus Torvalds created Git in 2005 for the development of the Linux kernel.
Features of Git
● Compatible with all operating systems: Git is compatible with almost all operating
systems that are available today. Even the repositories created by other version control
systems can be accessed by the Git repository.
● Allows for non-linear development: As users from remote parts of the world can
access the Git repository, work on it, and update the project at any time they want, Git
allows for development in a non-linear fashion. Git supports such a kind of
development by providing its branching and merging features, and it uses specific
tools for navigating through them. The projects are viewed in a tree form.
● Branches like a tree: While users are working on their projects, branches parallel to
the main project file are created, so the original code is not affected. There is no
restriction upon the number of branches created.
● Light as a cotton ball: One might think that making multiple copies of data from a
central repository to a local one will eventually lead the system to crash due to
overload. But, Git has got it covered. It compresses the data in such a way that it takes
up minimal space, and whenever you need to retrieve data, the reverse technique is
used. This helps save a lot of memory.
● Fast as a flash: Unlike other version control systems, Git is written in a language
known to be the closest to the machine language, that is, C. Hence, it processes
information much faster.
● Reliable: There will never be an issue of data loss as long as the copies of data in the
central repositories are available in the local repositories of different collaborators.
Git Architecture
Most of the version control systems have a two-tier architecture. However, Git has a
layer more, making it a three-tier architecture. But, why are there three layers of Git?
Let’s find out.
● Working directory: This is created when a Git project is initialised onto your
local machine and allows you to edit the source code copied.
● Staging area: Post the edits, the code is staged in the staging area by applying the
command, git add. This displays a preview for the next stage. In case further
modifications are made in the working directory, the snapshots for these two
layers will be different. However, these can be synced by using the same ‘git add’
command.
● Local repository: If no further edits are required to be done, then you can go
ahead and apply the git commit command. This replicates the latest snapshots in
all three stages, making them in sync with each other.
6. Commit
The git commit command is used to move files from the staging area to your local repository.
This command is run after git add and it can be seen as a checkpoint. After executing the git
commit, your staging area will be empty.
Suppose, you are on the master branch and you did a commit now git internally will create a
block i.e., a node, of a commit you did. In git, we have a pointer called HEAD (It is the
reference to the commit in the current branch in our case i.e., the master branch). When you
commit something the HEAD will be pointed to the new commit and a hash key is assigned
to that new commit. If you made another commit, again HEAD will move and point to the
commit having another hash key. It can be assumed as a right to left singly linked list,
whenever a new commit happens, a new node is created and points to HEAD, and after that
HEAD is updated and comes over the new commit i.e., the latest one.
There are certain flags in git commit like -a, -m, -am.
● Git commit -m “commit message”: A command which creates a commit with a
commit message written under quotation.
● Git commit -a: The command only includes modification to the files that have
been added with git add at any time i.e., all the tracked files.
● Git commit -am “commit message”: It is a combination of both the -m and -a
command.
Git Push
The push term refers to upload local repository content to a remote repository. Pushing is an
act of transfer commits from your local repository to a remote repository. Pushing is capable
of overwriting changes; caution should be taken when pushing.
Common usages and options for git push
● git push -f: Force a push that would otherwise be blocked, usually because it will
delete or overwrite existing commits (Use with caution!)
● git push -u origin [branch]: Useful when pushing a new branch, this creates an
upstream tracking branch with a lasting relationship to your local branch
● git push --all: Push all branches
● git push --tags: Publish tags that aren't yet in the remote repository
Git push origin master is a special command-line utility that specifies the remote branch and
directory. When you have multiple branches and directory, then this command assists you in
determining your main branch and repository.
Generally, the term origin stands for the remote repository, and master is considered as the
main branch. So, the entire statement "git push origin master" pushed the local content on
the master branch of the remote location.
Syntax:
Create a GitHub Account: If you don't already have a GitHub account, you'll need to
create one. You can sign up for free at https://github.com/.
Log In to GitHub: After creating an account, log in to your GitHub account.
Create a New Repository: To create a new project (repository), follow these steps:
● Click on the "+" icon in the upper right corner and select "New repository."
● Give your repository a name and optional description.
● Choose whether the repository should be public (visible to everyone) or
private (visible only to you and collaborators). Note that private repositories
often require a paid GitHub subscription.
● Select other options as needed (e.g., adding a README file, adding a
.gitignore file for specific programming languages, or choosing a license).
● Click the "Create repository" button.
Clone the Repository: To work on your project locally, you'll need to clone the
repository to your computer using Git. You can find the repository's URL on the
repository's page. Use the following command to clone the repository:
bash
Copy code
Add Your Project Files: Create or add your project files to the local repository folder
that you just cloned.
Commit and Push Changes: Use Git to commit your changes locally and push them to
the remote repository on GitHub. Here are the basic Git commands to do this:
bash
Copy code
git add .
git commit -m "Initial commit" # You can replace the message with a description of your
changes.
git push origin main # Use 'main' or 'master' depending on your default branch name.
Collaborate and Manage Your Project: You can add collaborators to your repository,
create branches, and manage issues and pull requests to collaborate with others.
Continuous Integration and Deployment (Optional): You can set up CI/CD
(Continuous Integration and Continuous Deployment) workflows using GitHub
Actions or other third-party tools to automate testing and deployment processes.
Documentation and README: It's essential to provide clear documentation in your
repository's README file to help others understand your project and how to use it.
Keep Your Project Updated: Regularly commit and push changes to keep your project
up to date on GitHub.
Remember to review and understand Git basics if you're new to version control systems.
GitHub provides extensive documentation to help you with various aspects of managing your
project and collaborating with others.
GITHUB
GitHub calls itself a code storage platform for version control that facilitates collaboration in
code development. The code of each project is stored in Repositories and offers us a variety
of tools that will help us both in the development and the administration of the project.
ISSUES
In essence, issues are text entries that developers or anyone can create. Issues can be used to
publicise a bug in the program, to describe upcoming features, or to describe user stories or
tasks.
The latter is very useful if we want to manage our project with the Scrum methodology. epics,
user stories, and tasks are important elements within this methodology. To create, describe,
and manage these components, issues have the following characteristics:
MARKDOWN
Markdown is a language mode for styling text, placing images and links. For a small glimpse
of everything it offers us, you can go to the following site. The body of the issues is written
with Markdown. So, in a simple way, we can place titles and subtitles, place a list of tasks,
place external links that help explain a task or user story and in the same way place images.
ASSIGNEES
Within a repository, regardless of whether it is public or private, we can add people and
assign these people to the issue. This allows us to have developers assigned to perform a task
and the people who review the code or compliance with user stories.
LABELS
Labels are keywords that are used to search between issues. They also provide essential
information on the type of the issue, its content or the current status. We can place labels to
differentiate the issues between epics, user stories and tasks. We can also place the
importance of a task, or if it is a design or development task.
PROJECTS
Projects are Kanban boards where we can add and manage repository issues. These help us to
have an overview of the status of all user stories and project tasks. Later in this article, I will
talk more in-depth about the projects.
MILESTONE
Milestones are issues grouped by a deadline or delivery time. These are very useful to have
our user stories and tasks grouped in Sprints.
ISSUE LINKING
Another important feature of issues is that connections to other issues can be placed in the
body. Each issue is identified with a unique correlative number. We can connect one issue to
another by placing a # followed by the issue number (#17). With this functionality, we can
connect a user story with all its tasks and vice versa, and it facilitates mobility between
issues.
Most developers only think of GitHub as a collaborative version control system. While this is
true, the platform has evolved to extend its functionality over the years. As a result, it is no
longer necessary to switch to a different tool to manage tasks, tickets, and reports.
GitHub offers a collection of features to support the Agile project management framework. It
is granted that GitHub isn’t the most powerful project management tool. But, it is still
invaluable for small teams that already use the platform to store, share, and collaborate on
code.
Furthermore, GitHub supports native integrations with more popular and powerful PM
platforms. This design makes it easy to scale your management capacity as your projects
grow and complexity increases.
Finally, GitHub’s project management capabilities are nested in its built-in features, namely:
● Project Boards
● Issues
● Labels
● Milestones
In the next section, we’ll discuss how these critical features support project management in
GitHub.
GitHub’s most fundamental element is the repository. This is where you store all your project
files, including each file’s revision history. Additionally, the platform offers various features
to manage and interact with your repository.
Now, some of these repository features are well suited to project management. These features
include:
Issues – Successful project management is mainly about tracking and organizing work.
GitHub Issues is a crucial feature for this purpose. Users can create issues for any number of
things, including requesting features, reporting bugs, and hosting discussions.
Furthermore, GitHub offers a dedicated dashboard for all your issues. You can even sort them
by category, such as issues you created, in which you are mentioned, or assigned to.
Project Boards – A Kanban board is a staple in Agile project management. The board helps
to maximize efficiency, limit work-in-progress, and visualize the workflow. GitHub features a
Kanban-style tool with its Project Boards.
You can even use the feature out-of-the-box with default templates. Alternatively, you can
build your board from scratch with the specific columns you need for your workflow.
Labels – A good project manager can prioritize issues and assign tasks. GitHub offers labels
to keep track of issues. For example, you can use color-coded labels to tag issues such as
feature requests, bugs, and discussions. This feature gives you a quick visual layout of all
your issues and tasks.
Milestones – Milestones in project management help measure progress towards the goal.
Again, GitHub provides a milestones feature to track progress on clusters of issues or pull
requests in your repository. Again, you get a quick visual of your progress in real-time.
Wikis – Finally, good project management calls for a central place to host all the project
documentation. GitHub makes this available with wikis. Wikis are built into your repository,
allowing you to detail the project’s documentation, including the project’s purpose, goal, core
principles, and other crucial information.
Below are a few examples of how you can use GitHub’s features for project management.
git rebase and git merge both of these commands are designed to integrate changes from one
branch into another branch—they just do it in very different ways.
Git Merge
Git merge is one of the merging techniques in git, in which the logs of commits on branches
are intact.
Let us take an example if we have a project with 3 commits on the master branch as commit
1,2,3 and feature branch commits as commit A and B. If we perform a git merge operation
then commits A and B will be merged as commit 4 onto the master branch. This is depicted
in Fig:9.
Fig 9: Before and after Git Merge.
The easiest option is to merge the main branch into the feature branch using something like
the following:
Advantages:
● The logs are very exhaustive and can help in understanding the complete history of
how and when each merge happened
● It is easy to find mistakes and resolve them.
Disadvantages:
Git-Rebase
Git Rebase is similar to git merge, but the logs are modified after merge in this technique. Git
rebase was introduced to overcome the limitation of merging, i.e., to make logs of repository
history look linear.
Let us take an example if we have a project with 3 commits on the master branch as commit
1,2,3 and feature branch commits as commit A and B. If we perform a git rebase operation
then the commits A and B will be rebased on to the master branch as commit 4 and 5 and
there will be no logs of the feature branches. This is depicted in Fig 12.
Advantages:
Disadvantages:
● We cannot track, when and how the commits were merged on the target branch
Git merge is a command that allows you to Git rebase is a command that allows
merge branches from Git. developers to integrate changes from one
branch to another.
In Git Merge logs will be showing the Logs are linear in Git rebase as the commits
complete history of the merging of are rebased
commits.
All the commits on the feature branch will All the commits will be rebased and the same
be combined as a single commit in the number of commits will be added to the
master branch. master branch.
Git Merge is used when the target branch is Git Rebase should be used when the target
shared branch branch is private branch
Git reset
The git reset command is used to undo the changes in your working directory and get back to
a specific commit while discarding all the commits made after that one.
For instance, imagine you made ten commits. Using git reset on the first commit will remove
all nine commits, taking you back to the first commit stage.
Before using git reset, it is important to consider the type of changes you plan to make;
otherwise, you will create more chaos than good.
You can use multiple options along with git reset, but these are the main ones. Each one is
used depending on a specific situation: git reset --soft, git reset --mixed, and git reset --hard
First thing, we need to find the point we want to return to. To do that, we need to go
through the log.
To avoid the very long log list, we are going to use the --oneline option, which gives just
one line per commit showing:
● The first seven characters of the commit hash - this is what we need to refer to in
our reset command.
● the commit message
We want to return to the commit: 9a9add8 (origin/master) Added .gitignore, the last one
before we started to mess with things.
Git Reset
We reset our repository back to the specific commit using git reset commithash (commithash
being the first 7 characters of the commit hash we found in the log):
Example
git reset 9a9add8
Now let's check the log again:
Example
Git Checkout
In Git, the term checkout is used for the act of switching between different versions of a
target entity. The git checkout command is used to switch between branches in a repository.
Be careful with your staged files and commits when switching between branches.
Checkout Branch
You can demonstrate how to view a list of available branches by executing the git
branch command and switch to a specified branch.
To demonstrate available branches in repository, use the below command:
1. $ git branch
Now, you have the list of available branches. To switch between branches, use the below
command.
Syntax:
Output:
Output:
In the above output, first, the fetch command is executed to fetch the remote data; after
that, the checkout command is executed to check out a remote branch.
Edited is my remote branch. Here, we have switched to edited branch from master
branch by git command line.
Git Fetch
Git "fetch" Downloads commits, objects and refs from another repository. It fetches
branches and tags from one or more repositories. It holds repositories along with the
objects that are necessary to complete their histories to keep updated remote-tracking
branches.
The "git fetch"command
The "git fetch" command is used to pull the updates from remote-tracking branches.
Additionally, we can get the updates that have been pushed to our remote branches to
our local machines.
We can fetch the complete repository with the help of fetch command from a repository
URL like a pull command does. See the below output:
Syntax:
We can fetch a specific branch from a repository. It will only access the element from a
specific branch. See the below output:
Syntax:
In the given output, the specific branch test has fetched from a remote URL.
The git fetch command allows you to fetch all branches simultaneously from a remote
repository. See the below example:
Syntax:
Output:
In the above output, all the branches have been fetched from the repository
Git-Example.
Suppose, your team member has added some new features to your remote repository.
So, to add these updates to your local repository, use the git fetch command. It is used as
follows.
Syntax:
Output:
Git Pull / Pull Request
The term pull is used to receive data from GitHub. It fetches and merges changes from
the remote server to your working directory. The git pull command is used to pull a
repository.
Pull request is a process for a developer to notify team members that they have
completed a feature. Once their feature branch is ready, the developer files a pull
request via their remote server account. Pull request announces all the team members
that they need to review the code and merge it into the master branch.
git pull
Syntax:
Output: