Advance Git & GitHub for DevOps Engineers: Part-2(Day10)

5 min readJul 2, 2024

Welcome to Day-10 of your DevOps journey! Continuing our DevOps series, today we will be diving into Advance Git & GitHub for DevOps Engineers(part-2).

In our previous discussion, we covered Advance Git & GitHub for DevOps Engineers (part-1). If you haven’t read it yet, you can check it out [here].

Task-01

Create a new branch and make some changes to it.
Use git stash to save the changes without committing them.
Switch to a different branch, make some changes and commit them.
Use git stash pop to bring the changes back and apply them on top of the new commits.

Git Stash:

Consider the case that you are working in a branch and you want to work in another branch as well without committing to the work. Well, git allows this using the git stash command. It allows you to save your work temporarily in the local branch allowing you to freely work anywhere.

To complete Task-01 using Git, follow these steps:

Create a new branch and make changes:

git checkout -b new-branch # Make your changes to files git add 
git commit -m "Made changes on new-branch"

Use git stash to save changes without committing:

git stash

Switch to a different branch, make changes, and commit them:

git checkout main # Make different changes git add 
git commit -m "Made changes on main branch"

Apply stashed changes on top of new commits:

git stash pop

This command will apply the stashed changes on top of your latest commit on the main branch.

These steps simulate a scenario where you work on two different branches, save changes temporarily with git stash, switch branches, make more changes, and then apply the stashed changes back onto your current branch.

Task-02

In version01.txt of development branch add below lines after “This is the bug fix in development branch” that you added in Day10 and reverted to this commit.
Line2>> After bug fixing, this is the new feature with minor alteration”
Commit this with message “ Added feature2.1 in development branch”
Line3>> This is the advancement of previous feature
Commit this with message “ Added feature2.2 in development branch”
Line4>> Feature 2 is completed and ready for release
Commit this with message “ Feature2 completed”
All these commits messages should be reflected in Production branch too which will come out from Master branch (Hint: try rebase).

Git Rebase:

The next thing we will be doing today is we will be adding a file to the dev branch and then will be committing it. We will add a file to the dev branch and commit it. We will also learn about the git rebase command, which is very useful.

git rebase allows us to integrate changes from one branch into another without creating a merge commit, thus maintaining a cleaner project history.

For example, if we rebase the main branch onto the feature branch, the changes from the feature branch will be integrated into the main branch. This process replays the commits from the feature branch onto the main branch, effectively incorporating all changes without altering the commit history of the main branch.

This technique helps in keeping the commit history linear and clean, which is especially useful for maintaining an understandable project history.

Key Points:

Rebase Explanation:

Rebasing allows integrating changes from one branch into another without creating a merge commit.
It replays commits from one branch onto another, which helps maintain a linear project history.

2. Rebasing Example:

Rebasing the main branch onto the feature branch integrates the changes from feature into main without altering the main branch’s commit history.

3. Benefits:

Keeps the commit history linear and clean.
Useful for maintaining an understandable project history.

[ In Git, a linear history means that the commit history follows a straight line, with each commit having a single parent, rather than having multiple branches and merge commits.

Get Araiz bin Saqib’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

A clean history is easy to read and understand, with fewer unnecessary merge commits. This makes it easier to track changes and understand the progression of the project. ]

Correct Usage of Rebase:

When you rebase, you’re effectively moving the base of the branch to a new starting point, which is the tip of another branch. Here’s how you can do it practically:

# Switch to the main branch
git checkout main

# Rebase the main branch onto the feature branch
git rebase feature

This command replays the commits from the feature branch onto the main branch, maintaining a clean and linear commit history.

Now to accomplish the task, you need to make changes and commit them to the development branch, then rebase these changes onto the production branch that comes from the master branch. Here’s a step-by-step guide:

Switch to the development branch:

git checkout development

2. Edit version01.txt and commit each change:

For Line2:

echo "After bug fixing, this is the new feature with minor alteration" >> version01.txt 
git add version01.txt 
git commit -m "Added feature2.1 in development branch"

For Line3:

echo "This is the advancement of previous feature" >> version01.txt 
git add version01.txt
git commit -m "Added feature2.2 in development branch"

For Line4:

echo "Feature 2 is completed and ready for release" >> version01.txt 
git add version01.txt
git commit -m "Feature2 completed"

3. Create and switch to a production branch from master:

git checkout master git checkout -b production

4. Rebase the development branch onto the production branch:

git checkout production git rebase development

By following these steps, you will have the same commit history in the production branch as you have in the development branch, with all the commits and their messages properly reflected.

Task-03

In Production branch Cherry pick Commit “Added feature2.2 in development branch” and added below lines in it:
Line to be added after Line3>> This is the advancement of previous feature
Line4>>Added few more changes to make it more optimized.
Commit: Optimized the feature

Git cherry-pick:

Now there arises a need to pick a specific commit from one branch and apply it to another branch. For this, we use the git cherry-pick command. Cherry-pick allows us to apply the changes from a specific commit to a different branch without merging the entire branch history.

Continuing the previous scenario in the production branch, I want to add more features after the addition of Feature 2.2, but I need to remove the line “Feature2 completed” because further modifications are needed. To do this, I will first cherry-pick the specific commit from the development branch, update the file as needed, and then commit these changes back without affecting the other branch.

Here’s how to do it:

Cherry-pick the specific commit:

git cherry-pick <commit-hash>

2. Edit the file to remove “Feature2 completed” and add new features.

3. Commit the changes:

git add version01.txt 
git commit -m "Optimized the feature and removed 'Feature2 completed' line"

By using git cherry-pick, we can selectively apply changes from one branch to another without disturbing the rest of the branch's history.

This explanation provides a clear understanding of what git cherry-pick does, how it can be used, and the specific steps to follow in your scenario.

This is how we can use the cherry-pick to commit changes from other branches. This becomes very handy when we need to use only some features from a particular branch in another one.

Hope you learned some more advanced concepts from this. We will continue them further as well.

Thank You for giving it a read.