Advance Git & GitHub for DevOps Engineers

day10 of 90daysofdevops

Git Branching

Git branching is a powerful feature of the Git version control system that allows you to create separate lines of development within a project. It enables multiple people to work on different aspects of a project simultaneously without interfering with each other's work.

Here's a short overview of Git branching:

Main Branch: The main branch, often called the "master" or "main" branch, represents the stable version of the project. It contains the production-ready code.
Creating a Branch: When starting a new feature or bug fix, you create a new branch that branches off from the main branch. This branch will contain all the changes related to that specific feature or bug fix.
Switching Branches: You can switch between branches using the "git checkout" command. This allows you to work on different branches at different times.
Committing Changes: As you make changes to your code, you commit them to the branch you're working on. Commits create a snapshot of your code at a specific point in time.
Merging Branches: Once you have finished working on a feature or bug fix, you can merge the branch back into the main branch. This combines the changes from the branch into the main branch, incorporating your work into the project.
Conflict Resolution: Sometimes, conflicts may occur when merging branches if changes in different branches affect the same file or lines of code. Git provides tools to help you resolve these conflicts manually.
Branch Management: Git provides various commands to manage branches, such as creating new branches, deleting branches, renaming branches, and listing existing branches.

By using branching effectively, you can organize your development workflow, collaborate with others, and keep your codebase clean and stable. It allows for parallel development and provides a way to isolate different features or experiments until they are ready to be integrated into the main codebase.

Git Revert and Reset

Git revert and reset are two commands used in Git to undo changes in a repository's history. While they both achieve similar results, they have different mechanisms and purposes. Here's a brief explanation of Git revert and reset:

Git Revert: The "git revert" command is used to create a new commit that undoes the changes made in a previous commit, effectively reverting the repository's history. This command is useful when you want to undo specific commits while keeping a record of the reversion.

When you run "git revert <commit>", Git will create a new commit that undoes the changes introduced in the specified commit.
The reverted commit remains in the history, but its changes are effectively canceled out by the new commit.
Other developers pulling or cloning the repository will see the reverted changes.

Git Reset: The "git reset" command is used to reset the current branch to a specific commit, discarding commits or moving branches to a different commit. This command is more powerful but potentially dangerous, as it modifies the repository's history.

There are three modes of "git reset": --soft, --mixed, and --hard, each with different consequences:
- "--soft" preserves the changes made in the commits, moving them to the staging area.
- "--mixed" is the default mode and preserves the changes but removes them from the staging area.
- "--hard" discards all changes, reverting the repository and working directory to the specified commit.

Git Rebase and Merge

Git rebase and merge are two different approaches for integrating changes from one branch into another in Git. Here's a brief explanation of Git rebase and merge:

Git Rebase: The "git rebase" command allows you to incorporate changes from one branch onto another by applying each commit from the source branch onto the target branch. It effectively moves or reapplies the commits of the source branch onto the tip of the target branch.

When you run "git rebase <source>", Git identifies the common ancestor of the source and target branches and replays each commit from the source branch onto the target branch.
The result is a linear history with all the changes from the source branch integrated into the target branch as new commits.
It's important to note that the commit objects are rewritten during the rebase process, potentially changing their commit IDs.
Rebasing is useful for keeping a clean, linear history, especially when working on feature branches or synchronizing with the main branch.

Git Merge: The "git merge" command combines the changes from one branch into another by creating a new commit that represents the merge of both branches.

When you run "git merge <source>", Git identifies the common ancestor of the source and target branches and creates a new commit that combines the changes from both branches.
The result is a commit that represents the integration of changes from the source branch into the target branch.
Merge commits have multiple parent commits, preserving the commit history of both branches.
Merging is suitable for integrating long-lived branches, such as feature branches or release branches, into the main branch.

Task 1:

Add a text file called version01.txt inside the Devops/Git/ with “This is first feature of our application” written inside. This should be in a branch coming from master, switch to dev branch. Make sure your commit message will reflect as "Added new feature"

Add new commit in dev branch after adding below mentioned content in Devops/Git/version01.txt: While writing the file make sure you write these lines