Autosave: 2023-03-24 08:54:27
This commit is contained in:
parent
ef87aa055d
commit
9f36118972
8 changed files with 97 additions and 4 deletions
|
@ -17,9 +17,9 @@ A remote is a git repository that is hosted on a server which you can interact w
|
|||
origin
|
||||
</dt>
|
||||
<dd>
|
||||
The default name given to the remote repository that was cloned. When you clone a repository, git automatically creates a default remote called `origin`. This is essentially an alias for the URL of this repoistory.
|
||||
The default name given to the remote repository that was cloned. When you clone a repository, git automatically creates a default remote called `origin`. This is essentially an alias for the URL of this repository.
|
||||
</dd>
|
||||
|
||||
<dt>HEAD</dt>
|
||||
<dd>A reference to the most recent commit on the currently checked-out branch. It points to the tip of the branch which is the commit that was most recently added. If you have changes in your working directory that have yet to be committed, the HEAD will be _behind_ them. Once you commit them, the HEAD will update to reflect the new commit.</dd>
|
||||
<dd>A reference to the most recent commit on the currently checked-out branch. It points to the tip of the branch which is the commit that was most recently added. If you have changes in your working directory that have yet to be committed, the HEAD will be behind them. Once you commit them, the HEAD will update to reflect the new commit.</dd>
|
||||
</dl>
|
||||
|
|
70
DevOps/Git/Interactive_staging.md
Normal file
70
DevOps/Git/Interactive_staging.md
Normal file
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
categories:
|
||||
- DevOps
|
||||
tags: [git]
|
||||
---
|
||||
|
||||
# Interactive staging
|
||||
|
||||
With interactive staging we can stage sub-portions of files rather than the whole file. This makes commits much more targetted and atomic.
|
||||
|
||||
## Basic use
|
||||
|
||||
We enter interactive mode with:
|
||||
|
||||
```
|
||||
git add -i
|
||||
```
|
||||
|
||||
This opens an interface:
|
||||
|
||||

|
||||
|
||||
We select 2 and it lets us stage by number. If I enter 1, it will stage the first change.
|
||||
|
||||
If we then go into 3 for revert, we can undo what we have staged.
|
||||
|
||||
> Note that untracked files are not automatically added to the changes. We have to manually add them with 4 ("add untracked").
|
||||
|
||||
> Interactive mode doesn't commit anything, it is only for staging.
|
||||
|
||||
## Working with patches and hunks
|
||||
|
||||
There's not much utility in interactive mode if you are commiting whole files. You can just use `git add [file]` and not bother with it.
|
||||
|
||||
But it is useful for staging sub-portions of a file, which are called **hunks**.
|
||||
|
||||
We access these via **patch mode**:
|
||||
|
||||

|
||||
|
||||
### Splitting hunks
|
||||
|
||||
Git will try to suggest the best hunks it can but these will sometimes not reflect the changes you want. Sometimes they will reflect multiple changes rather than a single change.
|
||||
|
||||
So long as there is an unchanged line between the different changes that it has selected as a hunk you can split the hunk further. You just hit `s` in patch mode, and it will repeatedly split the hunk each time until you get what you want.
|
||||
|
||||
This is still an automated process and you may not find that the splitting results in a hunk you want to commit. In this case you can use manual splitting mode. We enter this with `e`.
|
||||
|
||||
This will oped up Vim for the manual work to be done:
|
||||
|
||||

|
||||
|
||||
We use the diff symbols `+`, `-` and space to do this.
|
||||
|
||||
### Accessing patch mode directly
|
||||
|
||||
If we just want to go straight to patch mode, without anything else:
|
||||
|
||||
```
|
||||
git add -p
|
||||
```
|
||||
|
||||
We can also work with patches in the following commands:
|
||||
|
||||
```
|
||||
git stash -p
|
||||
git reset -p
|
||||
git restore -p
|
||||
git commit -p
|
||||
```
|
|
@ -46,4 +46,26 @@ git diff v1.0..v1.1
|
|||
|
||||
## Pushing tags to a remote
|
||||
|
||||
In the examples so far, all the tags have been **local tags**. They only exist in our local workflow and are not accessible to our collaborators. If we do a `git push`, this doesn't transfer our local tags.
|
||||
In the examples so far, all the tags have been **local tags**. They only exist in our local workflow and are not accessible to our collaborators. If we do a `git push`, this doesn't transfer our local tags. You have to do:
|
||||
|
||||
```
|
||||
git push origin [tag-name]
|
||||
```
|
||||
|
||||
Push all tags:
|
||||
|
||||
```
|
||||
git push origin --tags
|
||||
|
||||
# Delete remote tag
|
||||
|
||||
git push -d origin [tag-name]
|
||||
```
|
||||
|
||||
## Getting tags from the remote
|
||||
|
||||
```
|
||||
git fetch
|
||||
```
|
||||
|
||||
This automatically fetches tags too.
|
||||
|
|
BIN
_img/git-interactive-mode-2.png
Normal file
BIN
_img/git-interactive-mode-2.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 142 KiB |
BIN
_img/git-interactive-mode.png
Normal file
BIN
_img/git-interactive-mode.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 107 KiB |
BIN
_img/git-manual-hunk.png
Normal file
BIN
_img/git-manual-hunk.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 130 KiB |
BIN
_img/git-patch-mode.png
Normal file
BIN
_img/git-patch-mode.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 171 KiB |
|
@ -57,8 +57,9 @@
|
|||
- [ ] What is rebasing?
|
||||
- [ ] What is `git switch`
|
||||
- [x] What is cherry-picking
|
||||
- [ ] Tagging (also in relation to Git flow)
|
||||
- [x] Tagging (also in relation to Git flow)
|
||||
- [ ] How can you rollback without a hard-reset, i.e. how can you keep the future state (from the point of view of the rolled-back branch) accessible?
|
||||
- [ ] Difference between restore and reset
|
||||
|
||||
## JavaScript
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue