Autosave: 2023-03-20 13:39:43

DevOps/Git/Difference_between_remote_origin_and_head.md

@@ -0,0 +1,25 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Difference between _remote_, _origin_, _HEAD_
+
+<dl>
+<dt> remote
+</dt>
+<dd>
+A remote is a git repository that is hosted on a server which you can interact with over a network. You can have more than one remote for a local repository.
+</dd>
+
+<dt>
+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.
+</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>
+</dl>

DevOps/Git/Identify_merged_branches.md

@@ -0,0 +1,59 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Identify merged branches
+
+```sh
+# View merged
+git branch --merged
+
+# View merged remote
+git branch -r --merged
+
+# View unmerged
+git branch --no-merged
+
+# View unmerged remote
+
+git branch -r --no-merged
+```
+
+The above cases run the merge check from the point of view of HEAD as this is the default.
+
+But we can also run it from any branch.
+
+```
+git branch --merged non_head_branch
+```
+
+## Demonstration
+
+We have the following branches
+
+```
+git branch
+
+* main
+key_feature
+another_feature
+```
+
+The branches other than `main`, have not been merged:
+
+```
+git branch --merged
+
+* main
+```
+
+Just to confirm:
+
+```
+git branch --no-merged
+
+key_feature
+another_feature
+```

DevOps/Git/Remote_tracking_branches.md

@@ -0,0 +1,21 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Remote tracking branches
+
+A remote tracking branch is a **local** snapshot or reference to the state of a branch on a remote repository.
+
+When you clone a remote repository, Git automatically creates remote tracking branches for all the branches on the remote repository.
+
+The remote tracking branches have the prefix `origin/` followed by the name of the remote branch. For example, if you clone a repository with a branch named `develop`, Git creates a remote tracking branch named `origin/develop`.
+
+When you use commands like `git fetch` and `git pull`, you are interacting with the remote repository and having it reflected in the remote tracking branches.
+
+For instance, `git fetch` makes the remote tracking branch reflect the remote changes so that you have a local copy.
+
+The remote tracking branch is not the same as a local branch. A local branch is a branch that may or may not exist on the remote. Once it has been pushed to the remote repository, a remote tracking branch will be created for its remote version. When you make local changes, the snapshot of the remote tracking branch will no longer be up to date: your local branch will be "ahead" of it. Once you push, the remote tracking branch snapshot is update and reflects the local state of the branch and the two are in sync again.
+
+The same is true of remote branches. When you checkout a remote branch, your local version of it reflects a remote tracking version of it. This goes out of sync with your local version when changes are made on the remote.

DevOps/Git/Stale_branches_and_pruning.md

@@ -0,0 +1,21 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Stale branches and pruning
+
+A **stale branch** is a [remote tracking branch](/DevOps/Git/Remote_tracking_branches.md) that **no longer tracks anything** because the actual branch on the remote has been deleted.
+
+If _you_ delete the remote branch, the remote tracking branch will also be deleted. However if a _collaborator_ deletes the remote branch, your remote tracking branch will remain, becoming a stale branch.
+
+In order to get rid of it, we need to manually remove it. We can do this with the general `prune` command:
+
+```sh
+git remote prune origin
+
+# or run a preview of the action
+
+git remote prune origin --dry-run
+```

DevOps/Git/Tags_in_Git.md

@@ -0,0 +1,49 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Tags in Git
+
+Tags exist to reference specific commits in a more meaningful way than using a SHA reference. They are a **named reference to a commit**. As they refer to a singular commit they do not update but are a fixed point in the Git history.
+
+> Tags do not care about branches. They are an objective reference to a commit regardless of which branch it occured on. You can reference a tag without needing to be in the branch where the tagging originally took place.
+
+Tags are frequently used to mark software release versions. But they can also be used for other designations such as the addition of a key feature or bug.
+
+## Creating a tag
+
+```
+git tag -am "Version 1.0" v1.0 dd5c4539a0
+```
+
+`am` is for "annotated + message". The actual tag name is `v1.0`
+
+Now you can refer to that commit with `v1.0` rather than use the SHA
+
+## Deleting a tag
+
+```
+git tag -d v1.0
+```
+
+> When you delete the tag you are only deleting the tag reference not the commit that it refers to.
+
+## Listing tags
+
+```
+git tag --list
+```
+
+## Examples of use
+
+```
+git show v1.1
+
+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.

DevOps/Git/Viewing_remote_changes_without_merging.md

@@ -0,0 +1,13 @@
+---
+categories:
+  - DevOps
+tags: [git]
+---
+
+# Viewing remote changes without merging
+
+```
+git fetch origin/master
+git log origin/main
+git show origin/master
+```

_meta/Topic_Log.md

@@ -54,12 +54,11 @@
 
 ## Git
 
-- What is rebasing?
-- What is cherry-picking?
-- GitFlow methodology in the context of releases, hotfixes etc
-- 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?
-- Tagging (also in relation to Git flow)
-- See if there is an advanced Git course on LinkedIn
+- [ ] What is rebasing?
+- [ ] What is `git switch`
+- [x] What is cherry-picking
+- [ ] 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?
 
 ## JavaScript