0% found this document useful (0 votes)
29 views21 pages

Chapter 03

Devops ch3 which contains everything about vcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views21 pages

Chapter 03

Devops ch3 which contains everything about vcs
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Source Code Management:

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.

The most popular example is Git, Helix core, Microsoft TFS,

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

● Works on a distributed system: A distributed system is one that allows collaborators


to access the central repository using a VCS, even from the remotest corner of the
world. As Git maintains a snapshot every time a user pulls a file, the risk of data loss
due to system failure or lack of Internet connection is mitigated. Users are allowed to
work on the same bit of code simultaneously without getting interfered by others.

● 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.

The three layers are:

● 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.

The git command


The git clone command is used to create a copy of a specific repository or branch within
a repository. When you clone a repo you get a copy of the entire history of the repo. The
command used for cloning any repository is:
git clone <repository-link>

For Example: If you want to clone the Bootstrap repository.


In the above image, It’s a Bootstrap repository and you want to clone it in your local
system. For this, you have to use the link to clone this repository on your computer.
First, you have to go inside the folder in which you want to clone the repository, for this
use the cd command

Clone the repository using git clone <repo-link>

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.

Working with Git Commit

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.

Flags in Git Commit

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

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:

1. $ git push origin master

1. $ git add abc.jpg


2. $git commit -m "added a new image to project."
1. $ git push origin master

The file abc.jpg is successfully pushed to the origin master.

Git hub Project

​ 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

git clone https://github.com/your-username/your-repo.git


​ 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.

LINKED PULL REQUEST


Pull requests are a resource that is directly linked to development. When someone wants to
add functionality to the main branch or some restricted branch, they need to make a pull
request. This is so that CI/CD operations can be executed and the code can be reviewed
before adding it to the branch. Pull requests can be linked in the same way that issues are
linked in order to have a better follow-up of what is done in development.

What is GitHub Project Management Anyway?

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.

How GitHub Project Management Works

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 merge option

The easiest option is to merge the main branch into the feature branch using something like
the following:

git checkout feature


git merge main

Or, you can condense this to a one-liner:

git merge feature main

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:

● Results in a clumsy log / history


● Not very user-friendly

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.

Fig 12: Before and After git rebase


git checkout feature

git rebase main

Advantages:

● The logs are linear


● It’s easy to move through the project.

Disadvantages:

● We cannot track, when and how the commits were merged on the target branch

Git Merge Vs Git Rebase:


Merge Rebase

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

What is Git stash​


Stash is a Git command to locally store your recent changes in a separate area so you can
fetch those changes later. After taking a snapshot of your local files, it resets the state of your
workspace to the previous commit state. You can save multiple stashes on your local
computer and you can apply back any of the stashes at a later stage.
Stash is very simple to use. You can run git stash to save your changes and then use git stash
apply or git stash pop to bring back those saved changes.
Note that git stash is only applied to locally versioned files, and developers using the same git
repository will not be aware of these stash changes.

How to use Git stash​


Continuing the previous example of branch A and branch B, here is how you will use Git
stash to switch between branches while saving your changes locally without making a
commit.

1. Save changes to branch A which is your working branch.


2. Execute command git stash. It will preserve your changes locally in the stack.
3. Check out branch B.
4. Fix the bug in branch B.
5. Commit the changes and if you want to push to remote, then do that as well.
6. Switch back to branch A using checkout command
7. Run git stash pop to retrieve your stashed changes back.

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

Step 1: Find the previous commit:

Step 2: Move the repository back to that step:


After the previous chapter, we have a part in our commit history we could go back to.
Let's try and do that with reset.

Git Reset Find Commit in Log

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

So let's find the point we want to reset to:

git log --oneline


e56ba1f (HEAD -> master) Revert "Just a regular update, definitely no accidents here..."
52418f7 Just a regular update, definitely no accidents here...
9a9add8 (origin/master) Added .gitignore
81912ba Corrected spelling error
3fdaa5b Merge pull request #1 from w3schools-test/update-readme
836e5bf (origin/update-readme, update-readme) Updated readme for GitHub Branches
daf4f7c (origin/html-skeleton, html-skeleton) Updated index.html with basic meta
facaeae (gh-page/master) Merge branch 'master' of
https://github.com/w3schools-test/hello-world
e7de78f Updated index.html. Resized image
5a04b6f Updated README.md with a line about focus
d29d69f Updated README.md with a line about GitHub
e0b6038 merged with hello-world-images after fixing conflicts
1f1584e added new image
dfa79db updated index.html with emergency fix
0312c55 Added image to Hello World
09f4acd Updated index.html with a new line

221ec6e First release of Hello World!

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 log --oneline


9a9add8 (HEAD -> master, origin/master) Added .gitignore
81912ba Corrected spelling error
3fdaa5b Merge pull request #1 from w3schools-test/update-readme
836e5bf (origin/update-readme, update-readme) Updated readme for GitHub Branches
daf4f7c (origin/html-skeleton, html-skeleton) Updated index.html with basic meta
facaeae (gh-page/master) Merge branch 'master' of
https://github.com/w3schools-test/hello-world
e7de78f Updated index.html. Resized image
5a04b6f Updated README.md with a line about focus
d29d69f Updated README.md with a line about GitHub
e0b6038 merged with hello-world-images after fixing conflicts
1f1584e added new image
dfa79db updated index.html with emergency fix
0312c55 Added image to Hello World
09f4acd Updated index.html with a new line

221ec6e First release of Hello World!

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:

1. $ git checkout <branchname>

Output:

1. $ git checkout <remotebranch>

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.

Scenario 1: To fetch the remote repository:

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:

1. $ git fetch< repository Url>

Scenario 2: To fetch a specific branch:

We can fetch a specific branch from a repository. It will only access the element from a
specific branch. See the below output:

Syntax:

1. $ git fetch <branch URL><branch name>


Output:

In the given output, the specific branch test has fetched from a remote URL.

Scenario 3: To fetch all the branches simultaneously:

The git fetch command allows you to fetch all branches simultaneously from a remote
repository. See the below example:

Syntax:

1. $ git fetch -all

Output:

In the above output, all the branches have been fetched from the repository
Git-Example.

Scenario 4: To synchronize the local repository:

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:

1. $ git fetch origin

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

git pull <remote> <branch>

git pull origin develop

Syntax:

1. $ git pull <remote branch URL>

Output:

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy