• repository: A repository is a collection of commits, each of which is an archive of what the project’s working tree looked like at a past date, whether on your machine or someone else’s. It also defines HEAD (see below), which identifies the branch or commit the current working tree stemmed from. Lastly, it contains a set of branches and tags, to identify certain commits by name.
• index: Git does not commit changes directly from the working tree into the repository. Instead, changes are first registered in something called the index. Think of it as a way of “confirming” your changes, one by one, before doing a commit (which records all your approved changes at once). Some find it helpful to call it instead as the “staging area”, instead of the index.
• working tree: A working tree is any directory on your filesystem which has a repository associated with it (typically indicated by the presence of a sub-directory within it named .git.). It includes all the files and sub-directories in that directory.
• commit: A commit is a snapshot of your working tree at some point in time. The state of HEAD (see below) at the time your commit is made becomes that commit’s parent. This is what creates the notion of a “revision history”.
• HEAD: is used by your repository to define what is currently checked out. If you checkout a branch, HEAD symbolically refers to that branch, indicating that the branch name should be updated after the next commit operation. If you checkout a specific commit, HEAD refers to that commit only. This is referred to as a detached HEAD, and occurs, for example, if you check out a tag name.

• show status including untracked files: git status -u

• show history: git log --graph --decorate --oneline
• show history with graph: git log --graph --abbrev-commit --decorate

• delete a remote Git tag: git push --delete origin <tag_name>
• delete a local Git tag: git tag -d <tag_name>
• list tags: git tag -l
• creating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command: git tag -a v1.4 -m 'my version 1.4'. The -m specifies a tagging message, which is stored with the tag. If you donít specify a message for an annotated tag, Git launches your editor so you can type it in.
• push your tags to your remote repo: git push origin --tags
• if you just want to push a single tag: git push origin <tag>

• all first-time push on new branches will automatically set the default upstream: git config --global push.autoSetupRemote true

• reset last commit: git reset --soft HEAD~1
• show commits where a particular file was changed: git log --follow -- <filename>
• squash all commits on master:

git reset --soft id-of-first-revision-of-master
git commit --amend -m "single commit for master"
git push --force

To squash commits together:

git rebase -i starting_commit_hash

# Let the name of the Release branch be release and the name of the Feature branch be feature.
# Rebasing can be done using the following commands:

git checkout feature
git rebase release

# if there is a conflict, Git will notify you, and you will have to resolve the conflict manually. After the conflict is resolved use the following commands to continue rebasing
git add fixedfile
git rebase --continue

• avoid "Are you sure you want to continue connecting (yes/no)?": git clone -c core.sshCommand='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"' [email protected]:romitagl/kgraph.git

  or: git config core.sshCommand "ssh -i /root/.ssh/id_rsa -o 'IdentitiesOnly yes'"

• adding an existing Git repository as a submodule of the repository that we’re working on: git submodule add <git-repository> [folder-name]

Fork a repo on GitHub and clone the fork (not the original repo).

Configure the upstream remote in addition to origin. In the example [email protected]:nolar/kopf.git is used:

git remote add upstream [email protected]:nolar/kopf.git
git fetch upstream

Sync your main branch with the upstream regularly:

git checkout main
git pull upstream main --ff
git push origin main

Work in the feature branches of your fork, not in the upstream’s branches:

Create a feature branch in the fork:

git checkout -b feature-x
git push origin feature-x

Once the feature is ready, create a pull request from your fork to the main repo.

git archive --format=tar.gz -o branch.tar.gz -v branch

git archive master | bzip2 > source-tree.tar.bz2

First, turn off compression:

git config --global core.compression 0

Next, let's do a partial clone to truncate the amount of info coming down:

git clone --depth 1 <repo_URI>

When that works, go into the new directory and retrieve the rest of the clone:

git fetch --unshallow

Now, do a regular pull:

git pull --all

• GitHub formatting: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting