Git Branching
Use a branch to isolate development work without affecting other branches in the repository. Each repository has one default branch, and can have multiple other branches. You can merge a branch into another branch using a pull request.
Branches allow you to develop features, fix bugs, or safely experiment with new ideas in a contained area of your repository.
Git Revert and Reset
Two commonly used tools that git users will encounter are those of git reset and git revert . The benefit of both of these commands is that you can use them to remove or edit changes you’ve made in the code in previous commits.
The git revert command is a forward-moving undo operation that offers a safe method of undoing changes. Instead of deleting or orphaning commits in the commit history, a revert will create a new commit that inverses the changes specified. Git revert is a safer alternative to git reset in regards to losing work.
The git reset is the command we use when we want to move the repository back to a previous commit, discarding any changes made after that commit.
Step 1: Find the previous commit:
Step 2: Move the repository back to that step:
Git Rebase and Merge
What Is Git Rebase?
Git rebase is a command that lets users integrate changes from one branch to another, and the logs are modified once the action is complete. Git rebase was developed to overcome merging’s shortcomings, specifically regarding logs.
What Is Git Merge?
Git merge is a command that allows developers to merge Git branches while the logs of commits on branches remain intact.
The merge wording can be confusing because we have two methods of merging branches, and one of those ways is actually called “merge,” even though both procedures do essentially the same thing.
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
git clone <URL>
Make sure you are present in the main branch, Create branch dev
git branch <branch name>
git checkout <branch name>
Create a file name version01.txt & add content to it "This is the feature of our application"
vim version01.txt
Now add and commit it with message "new feature added"
git commit -m "new feature added"
Task 2
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
1st line>> This is the bug fix in development branch
Commit this with message “ Added feature2 in development branch”
2nd line>> This is gadbad code
Commit this with message “ Added feature3 in development branch
3rd line>> This feature will gadbad everything from now.
Commit with message “ Added feature4 in development branch
For this, just add and commit each time a change is made and and changes can be verfied using:
git log
Task 2:
Demonstrate the concept of branches with 2 or more branches with screenshot.
add some changes to
devbranch and merge that branch inmasteras a practice try git rebase too, see what difference you get.
Below you can see two branches out of master branch, which can be created for working on different features on the master branch
git branch
As we have already made changes to dev branch, lets merge it to master
git checkout master
When we open the git master branch we can see that there isnt a version01.txt file as it is created in dev branch.
Being in master branch, try to merge dev branch to master:
git merge <branch to merge to current branch>
Do ll and check:
The version01.txt can be seen in the master branch.
Git Rebase
In Git merge, what we do is take make a branch from the master branch or any branch for that matter to add some features. Later, we add commits to it and then merge the branch back with its parent branch from which it was created. This creates a workflow that looks something like this -
This, when done on a major scale or when added too many branches or features would look like a complicated tree of branches.
To overcome this Rebase is a better workflow option. What it does is it adds the commits that were made in the branch ahead of the master branch commits that existed before merging the file. The workflow would look something like this :
This makes the structure look less complex and understandable.
Lets try doing a commit on dev branch and rebase it to master.
Thank you!