corrected spelling mistake (#362)
* corrected spelling mistake * changed text to code in git/README.md * corrected spelling mistake
This commit is contained in:
Pranay K. Singh
GitHub
parent
0939fd7996
commit
58d0a20307
@ -3,7 +3,7 @@
|
||||
## Exercises
|
||||
|
||||
| Name | Topic | Objective & Instructions | Solution | Comments |
|
||||
|--------|--------|------|----|----|
|
||||
| ----------------- | ------ | -------------------------------- | ------------------------------------------- | -------- |
|
||||
| My first Commit | Commit | [Exercise](commit_01.md) | [Solution](solutions/commit_01_solution.md) | |
|
||||
| Time to Branch | Branch | [Exercise](branch_01.md) | [Solution](solutions/branch_01_solution.md) | |
|
||||
| Squashing Commits | Commit | [Exercise](squashing_commits.md) | [Solution](solutions/squashing_commits.md) | |
|
||||
@ -113,10 +113,10 @@ Finally, with certain build systems, you can know which files are being used/rel
|
||||
<details>
|
||||
<summary>What's is the branch strategy (flow) you know?</summary><br><b>
|
||||
|
||||
* Git flow
|
||||
* GitHub flow
|
||||
* Trunk based development
|
||||
* GitLab flow
|
||||
- Git flow
|
||||
- GitHub flow
|
||||
- Trunk based development
|
||||
- GitLab flow
|
||||
|
||||
[Explanation](https://www.bmc.com/blogs/devops-branching-strategies/#:~:text=What%20is%20a%20branching%20strategy,used%20in%20the%20development%20process).
|
||||
|
||||
@ -137,6 +137,7 @@ git pull
|
||||
git checkout devel
|
||||
git merge main
|
||||
```
|
||||
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -154,7 +155,7 @@ Using the HEAD file: `.git/HEAD`
|
||||
<details>
|
||||
<summary>What <code>unstaged</code> means in regards to Git?</summary><br><b>
|
||||
|
||||
A file the is in the working directory but is not in the HEAD nor in the staging area, referred to as "unstaged".
|
||||
A file that is in the working directory but is not in the HEAD nor in the staging area is referred to as "unstaged".
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -168,9 +169,12 @@ True
|
||||
<details>
|
||||
<summary>You have two branches - main and devel. How do you merge devel into main?</summary><br><b>
|
||||
|
||||
```
|
||||
git checkout main
|
||||
git merge devel
|
||||
git push origin main
|
||||
```
|
||||
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -203,8 +207,8 @@ This page explains it the best: https://git-scm.com/docs/merge-strategies
|
||||
|
||||
Probably good to mention that it's:
|
||||
|
||||
* It's good for cases of merging more than one branch (and also the default of such use cases)
|
||||
* It's primarily meant for bundling topic branches together
|
||||
- It's good for cases of merging more than one branch (and also the default of such use cases)
|
||||
- It's primarily meant for bundling topic branches together
|
||||
|
||||
This is a great article about Octopus merge: http://www.freblogg.com/2016/12/git-octopus-merge.html
|
||||
</b></details>
|
||||
@ -218,6 +222,7 @@ This is a great article about Octopus merge: http://www.freblogg.com/2016/12/git
|
||||
|
||||
`git reset` depends on the usage, can modify the index or change the commit which the branch head
|
||||
is currently pointing at.
|
||||
|
||||
</p>
|
||||
</b></details>
|
||||
|
||||
@ -240,6 +245,7 @@ Suppose a team is working on a `feature` branch that is coming from the `main` b
|
||||
```
|
||||
git checkout HEAD~1 -- /path/of/the/file
|
||||
```
|
||||
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -250,15 +256,14 @@ git checkout HEAD~1 -- /path/of/the/file
|
||||
<summary>What is the <code>.git</code> directory? What can you find there?</summary><br><b>
|
||||
The <code>.git</code> folder contains all the information that is necessary for your project in version control and all the information about commits, remote repository address, etc. All of them are present in this folder. It also contains a log that stores your commit history so that you can roll back to history.
|
||||
|
||||
|
||||
This info copied from [https://stackoverflow.com/questions/29217859/what-is-the-git-folder](https://stackoverflow.com/questions/29217859/what-is-the-git-folder)
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What are some Git anti-patterns? Things that you shouldn't do</summary><br><b>
|
||||
|
||||
* Not waiting too long between commits
|
||||
* Not removing the .git directory :)
|
||||
- Not waiting too long between commits
|
||||
- Not removing the .git directory :)
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -341,13 +346,13 @@ Shortly, it runs `git diff` twice:
|
||||
|
||||
One reason is about the structure of the index, commits, etc.
|
||||
|
||||
* Every file in a commit is stored in tree object
|
||||
* The index is then a flattened structure of tree objects
|
||||
* All files in the index have pre-computed hashes
|
||||
* The diff operation then, is comparing the hashes
|
||||
- Every file in a commit is stored in tree object
|
||||
- The index is then a flattened structure of tree objects
|
||||
- All files in the index have pre-computed hashes
|
||||
- The diff operation then, is comparing the hashes
|
||||
|
||||
Another reason is caching
|
||||
|
||||
* Index caches information on working directory
|
||||
* When Git has the information for certain file cached, there is no need to look at the working directory file
|
||||
- Index caches information on working directory
|
||||
- When Git has the information for certain file cached, there is no need to look at the working directory file
|
||||
</b></details>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user