GitHub/school-of-sre
1
0
Fork 0
mirror of https://github.com/linkedin/school-of-sre synced 2026-01-05 08:08:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs (level 101): fix typos, punctuation, formatting (#160)

Browse Source 
* docs: formatted for readability

* docs: rephrased and added punctuation

* docs: fix typos, punctuation, formatting

* docs: fix typo and format

* docs: fix caps and formatting

* docs: fix punctuation and formatting

* docs: capitalized SQL commands, fixed puntuation, formatting

* docs: fix punctuation

* docs: fix punctuation and formatting

* docs: fix caps,punctuation and formatting

* docs: fix links, punctuation, formatting

* docs: fix code block formatting

* docs: fix punctuation, indentation and formatting
This commit is contained in:
Jana R
2024-07-28 17:38:19 +05:30
committed by GitHub
parent bdcc6856ed
commit 4239ecf473
58 changed files with 1522 additions and 1367 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
courses/level101/git/branches.md
View File

@@ -1,6 +1,6 @@
# Working With Branches
Coming back to our local repo which has two commits. So far, what we have is a single line of history. Commits are chained in a single line. But sometimes you may have a need to work on two different features in parallel in the same repo. Now one option here could be making a new folder/repo with the same code and use that for another feature development. But there's a better way. Use _branches._ Since git follows tree like structure for commits, we can use branches to work on different sets of features. From a commit, two or more branches can be created and branches can also be merged.
Coming back to our local repo which has two commits. So far, what we have is a single line of history. Commits are chained in a single line. But sometimes you may have a need to work on two different features in parallel in the same repo. Now one option here could be making a new folder/repo with the same code and use that for another feature development. But there's a better way. Use _branches_. Since git follows tree-like structure for commits, we can use branches to work on different sets of features. From a commit, two or more branches can be created and branches can also be merged.
Using branches, there can exist multiple lines of histories and we can checkout to any of them and work on it. Checking out, as we discussed earlier, would simply mean replacing contents of the directory (repo) with the snapshot at the checked out version.
@@ -13,7 +13,7 @@ $ git log --oneline --graph
* df2fb7a adding file 1
```
We create a branch called `b1`. Git log tells us that b1 also points to the last commit (7f3b00e) but the `HEAD` is still pointing to master. If you remember, HEAD points to the commit/reference wherever you are checkout to. So if we checkout to `b1`, HEAD should point to that. Let's confirm:
We create a branch called `b1`. Git log tells us that `b1` also points to the last commit (`7f3b00e`) but the `HEAD` is still pointing to `master`. If you remember, `HEAD` points to the commit/reference wherever you are checkout to. So if we checkout to `b1`, `HEAD` should point to that. Let's confirm:
```bash
$ git checkout b1
@@ -23,7 +23,7 @@ $ git log --oneline --graph
* df2fb7a adding file 1
```
`b1` still points to the same commit but HEAD now points to `b1`. Since we create a branch at commit `7f3b00e`, there will be two lines of histories starting this commit. Depending on which branch you are checked out on, the line of history will progress.
`b1` still points to the same commit but `HEAD` now points to `b1`. Since we create a branch at commit `7f3b00e`, there will be two lines of histories starting this commit. Depending on which branch you are checked out on, the line of history will progress.
At this moment, we are checked out on branch `b1`, so making a new commit will advance branch reference `b1` to that commit and current `b1` commit will become its parent. Let's do that.
@@ -44,7 +44,7 @@ $ git log --oneline --graph
$
```
Do note that master is still pointing to the old commit it was pointing to. We can now checkout to master branch and make commits there. This will result in another line of history starting from commit 7f3b00e.
Do note that master is still pointing to the old commit it was pointing to. We can now checkout to `master` branch and make commits there. This will result in another line of history starting from commit `7f3b00e`.
```bash
# checkout to master branch
@@ -66,7 +66,7 @@ $ git log --oneline --graph
* df2fb7a adding file 1
```
Notice how branch b1 is not visible here since we are on the master. Let's try to visualize both to get the whole picture:
Notice how branch `b1` is not visible here since we are on the `master`. Let's try to visualize both to get the whole picture:
```bash
$ git log --oneline --graph --all
@@ -77,13 +77,13 @@ $ git log --oneline --graph --all
* df2fb7a adding file 1
```
Above tree structure should make things clear. Notice a clear branch/fork on commit 7f3b00e. This is how we create branches. Now they both are two separate lines of history on which feature development can be done independently.
Above tree structure should make things clear. Notice a clear branch/fork on commit `7f3b00e`. This is how we create branches. Now they both are two separate lines of history on which feature development can be done independently.
**To reiterate, internally, git is just a tree of commits. Branch names (human readable) are pointers to those commits in the tree. We use various git commands to work with the tree structure and references. Git accordingly modifies contents of our repo.**
## Merges
Now say the feature you were working on branch `b1` is complete and you need to merge it on master branch, where all the final version of code goes. So first you will checkout to branch master and then you pull the latest code from upstream (eg: GitHub). Then you need to merge your code from `b1` into master. There could be two ways this can be done.
Now say the feature you were working on branch `b1` is complete and you need to merge it on `master` branch, where all the final version of code goes. So first, you will `checkout` to branch `master` and then you `pull` the latest code from `upstream` (eg: GitHub). Then you need to merge your code from `b1` into `master`. There could be two ways this can be done.
Here is the current history:
@@ -96,7 +96,7 @@ $ git log --oneline --graph --all
* df2fb7a adding file 1
```
**Option 1: Directly merge the branch.** Merging the branch b1 into master will result in a new merge commit. This will merge changes from two different lines of history and create a new commit of the result.
**Option 1: Directly merge the branch.** Merging the branch `b1` into `master` will result in a new merge commit. This will merge changes from two different lines of history and create a new commit of the result.
```bash
$ git merge b1
@@ -114,9 +114,9 @@ $ git log --oneline --graph --all
* df2fb7a adding file 1
```
You can see a new merge commit created (8fc28f9). You will be prompted for the commit message. If there are a lot of branches in the repo, this result will end-up with a lot of merge commits. Which looks ugly compared to a single line of history of development. So let's look at an alternative approach
You can see a new merge commit created (`8fc28f9`). You will be prompted for the commit message. If there are a lot of branches in the repo, this result will end-up with a lot of merge commits. Which looks ugly compared to a single line of history of development. So let's look at an alternative approach.
First let's [reset](https://git-scm.com/docs/git-reset) our last merge and go to the previous state.
First, let's [reset](https://git-scm.com/docs/git-reset) our last merge and go to the previous state.
```bash
$ git reset --hard 60dc441
@@ -129,7 +129,7 @@ $ git log --oneline --graph --all
* df2fb7a adding file 1
```
**Option 2: Rebase.** Now, instead of merging two branches which has a similar base (commit: 7f3b00e), let us rebase branch b1 on to current master. **What this means is take branch `b1` (from commit 7f3b00e to commit 872a38f) and rebase (put them on top of) master (60dc441).**
**Option 2: Rebase.** Now, instead of merging two branches which has a similar base (commit: `7f3b00e`), let us rebase branch `b1` on to current master. **What this means is take branch `b1` (from commit `7f3b00e` to commit `872a38f`) and rebase (put them on top of) master (`60dc441`).**
```bash
# Switch to b1