git branch <branchname>
  git switch -c <branchname>

  #   Create a new branch off of a specific commit hash
  git switch -c <branchname> <commit hash>

  git checkout <branchname>          # only works if <branchname> exits

  git branch -d <branchname>        # delete branch
  git branch -D <branchname>        # force delete a branch (unmerged commits)

When you create a branch:

• git uses the current commit you are on as the branch base
• HEAD moves to that branch

After deleting a branch

• The commits from that branch will no longer be visible in git log
• Even with git log --all, you will no longer see any unmerged commits from that branch
• Commits will still be visible in reflog

tip = most recent commit in a branch

HEAD = commit you are working off of

HEAD usually will be the tip, but does not necessarily have to be.

The commit hash of HEAD of a branch is stored in .git/refs/heads

HEAD is stored in a file:

• .git/HEAD
• This points to the branch HEAD stored in .git/refs/heads

• Commit which merges two branches with diverging histories.
• Only kind of commit with two parent commits.
• Relative to Merge Base, aka best common ancestor

  git merge <feature_branch_name>            # usually done from main branch

• Simplest
• Tip of feature branch becomes the tip of main branch
• NO MERGE COMMITS
• Feature branch is merged into the main branch prior to additional main branch commits

• Out of habit, it is a good idea not to rebase your own private/fork main branches

• Rebase will change commit hashes

• Will have to address conflicts if rebasing:

  • If there are conflicts in rebasing there would be conflicts in merging as well
  • Merging does not have any benefits over rebasing in this regard
  • Generally if there are no conflicts in a merge, there will be no conflicts in rebase

• Rebase advantage:

  • Reverting commits
  • Only really done at scale

• Merge advantage:

  • Shows true history

• Merge vs rebase might be enforced by some teams on the main branch

  • For your own branches you can generally do whatever you want.

• An opinionated strategy:

  • Always rebase
  • All merges then become fast-forward merges
  • If you are in a situation where you need to revert, it becomes really easy to do.
  • Squashing becomes easy

With merge conflict resolution

• you COMMIT the resolution

    git add <file>
    git commit [-m "Message"]

With rebase conflict resolution

• you CONTINUE the resolution

    git rebase --continue

• you DO NOT commit rebase resolution

If you happen to accidentally commit rebase resolutiton

• undo the commit

    git reset --soft HEAD~1

• then continue the rebase

  git reset --soft <commit hash>
  git reset --soft HEAD~1         # go back one commit from HEAD

• Undo the last commit and committed changes in the index (staged but not committed)
• Commit changes will be uncommited and staged
• Uncommited changes will remain staged or unstaged as before

  git reset --hard <commit hash>

• Makes working directory and staging area match the last commit exactly
• Disregards local changes

Rather than soft resetting to change a commit message, you can just do this:

  # this is a destructive item because it changes the commit hash
  # only do for latest commit which is not merged to main
  git commit --amend

This is a destructive operation and will change the commit hash.

• This fetches objects and bookeeping information about a repo into .git/objects
• It does not pull the files into your local branch(es).

.git/info/exclude

• Alternative to .gitignore
• Allows your personal ignored files to not be part of the repo
• Team members cannot see what kind of shady stuff you're hiding from the repo

• .gitignore does not have to be a t the project root
• There can be .gitignore in any directory of the project

Patterns starting with a forward slash are anchored to that directory

• /main.py would ignore main.py in the root directory but not any other directories
• "*" matches any number of characters except forward-slash
• "#" comments

• "!" indicates negation: negate specific files that would otherwise be ignored

    ,*.txt
    !/important.txt                 # negates important.txt despite the *.txt wildcard

Order matters:

• one entry can override another

• correct:

    temp/*
    !temp/instructions.md      # this ignores all temp/ files except for instructions.md

• incorrect:

    !temp/instructions.md
    temp/*                          # this overrides the above negation

Ignore things that can be generated or sensitive data

• compiled code
• minified files
• dependencies (e.g. node_modules, venv, packages, etc.)
• personal or specific preferences (e.g. editor settings)
• sensitive or dangerous things (e.g. .env files, passwords, API keys, etc.)

• Want to contribute to the project

• Add second remote called upstream which points to original repo

    git remote add upstream <uri>

  • Can bring in latest changes to your fork

Review code on the actual git forge site

• Different look than your editor
• Removes bias, potentially see stuff differently

Make sure maintainers want these changes

• Look for issues
• Consider creating an issue beforehand

In the contributors/ directory, add:

• A file with your forge username.txt
• A link to your forge profile in the text

• Use git reflog to find the commit hash of the now deleted commit.

• Use git cat-file -p <hash> to get the tree

    git cat-file -p <commithash>    # gets the tree
    git cat-file -p <tree>          # gets the blob
    git cat-file -p <blob>          # gets the file-hash
    git cat-file -p <file-hash>     # shows contents of file

The TOP changes are OURS

• Should indicating HEAD (which is always local/ours)

    <<<<<<<< HEAD

The BOTTOM changes are THEIRS

• Should indicate the branch, e.g. main

    >>>>>>>> main

You can manually accept both changes.

To reset to a specific commit:

  git reset --hard <commit hash>

The git checkout command can checkout the individual changes during a merge conflict using the –theirs or –ours flags.

• –ours keeps the version of the file from your current branch (the one you're on before merging)
• –theirs uses the version of the file from the branch you're merging into your current branch

  git checkout --theirs <path/to/file>
  git checkout --ours <path/to/file>

After rebasing main on the feature branch and conflict arises:

• Check the branch

  • YOU WILL NOT BE ON ANY BRANCH
  • your branch will be: (no branch, rebasing <featurebranch>)

• This is called detached HEAD

  • temporary state
  • allows you to resolve the conflict before proceeding with the rebase

Use git checkout –theirs and git checkout –ours In a merge

• –ours refers to your current branch

• this is most likely MAIN/MASTER

  • sinced based bros will be rebasing onto a feature branch
  • and only (fast forward) merging onto main/master

In a rebase

• –ours refers to the branch you're rebasing onto.
• in this case we are rebasing from the feature branch onto a different branch
• it is probably main/master

"Accept current change" is the same as

  git checkout --ours <filepath>

• <<<<<<
• top portion of the conflicting file

"Accept incoming change" is the same as

  git checkout --theirs <filepath>

• >>>>>>
• bottom portion of the conflicting file

  git rebase --continue

  git log --oneline --all

  wagslane@MacBook-Pro-2 megacorp % git rebase main
  Auto-merging customers/favs.md
  CONFLICT (add/add): Merge conflict in customers/favs.md
  error: could not apply ad9b194... K
  hint: Resolve all conflicts manually, mark them as resolved with
  hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
  hint: You can instead skip this commit: run "git rebase --skip".
  hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
  Recorded preimage for 'customers/favs.md' # <--- THIS LINE HERE
  Could not apply ad9b194... K

NOTICE:

  Recorded preimage for 'customers/favs.md' # <--- THIS LINE HERE

Rerere is now recording how to resolve the conflict

• Either accept –ours (main) or –theirs (favs branch)
• Or accept both by manually editing the file

If we recreate the same conflict from another (third) branch (favs2)

  wagslane@MacBook-Pro-2 megacorp % git rebase main
  Auto-merging customers/favs.md
  CONFLICT (add/add): Merge conflict in customers/favs.md
  error: could not apply ad9b194... K
  hint: Resolve all conflicts manually, mark them as resolved with
  hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
  hint: You can instead skip this commit: run "git rebase --skip".
  hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
  Resolved 'customers/favs.md' using previous resolution. # <--- THIS LINE HERE
  Could not apply ad9b194... K

NOTICE

  Resolved 'customers/favs.md' using previous resolution. # <--- THIS LINE HERE

• if you open the conflicting file, the changes have already been made to match the first one

Continue the rebase with

  git rebase --continue

1. Identify the main branch remote

   • Might have to reset this
   • Most likely origin

2. Create a temporary branch

   • Rebase is destructive

3. Perform the rebase on temp branch

   • Emacs git-rebase-mode has its own keybindings; do not need to directly edit, just press "s" on all lines that should be changed from "pick" to "squash"

4. Delete the main branch

     git branch -d main

5. Rename temp branch to main

     git branch -m temp_main main

6. Push and reset the main branch remote

     git push -u origin main
     # git might suggest:
     # git push --set-upstream origin main
     # which does the same thing

Force push required because this is a destructive operation on the remote main

  git push origin main --force

Your git history is rewritten, but full history is still accessible with reflog.

The git stash command stores your changes in a stack (LIFO) data structure. That means that when you retrieve your changes from the stash:

• You'll always get the most recent changes first.
• Stores index and worktree.

git reset --soft: Undo commits but keep changes staged

git reset --hard: Undo commits and discard changes

git revert: Create a new commit that undoes a previous commit

When to Reset?:

• Working on your own branch,
• Just undoing something you've already committed,
• E.g cleaning everything up so you can open a pull request

When to Revert?:

• Undo a change that's already on a shared/public branch (especially if it's an older change)
• It won't rewrite any history, and therefore won't step on your coworkers' toes.

From the git bisect man page:

Bisect run If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command:

$ git bisect run my_script arguments

Note that the script (my_script in the above example) should exit with code 0 if the current source code is good/old, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.

This could be accomplished by a script that:

• searches a file for whatever the problem is
• returns 0 if the source is good
• returns 1+ if the source is bad

For example:

  #!/bin/sh
  # bisect-script.sh
  if grep -q "SCANNING" "scripts/scan.sh"; then
      exit 1
  else
      exit 0
  fi

• save and mark this script as executable somewhere in the repo
• mark your good and bad initial commits

Then run:

  git besect run ./bisect-script.sh

• Contains the .git directory with the entire state of the repo
• Heavy (lots of data)
• A new main working tree requires a git clone or git init.

• Contains a .git file with a path to the main working tree
• Light (essentially no data), about as light as a branch.
• Can be complicated to work with when it comes to env files and secrets.

  git worktree add <path> <branch> # create a new linked worktree

Linked worktrees behave just like a "normal" git repo. You can:

• create new branches
• switch branches
• delete branches
• create tags
• etc

BUT there is one thing you cannot do:

• you cannot work on a branch that is currently checked out by any other working tree (main or linked worktree).

Example: try to switch to main/master from a linked worktree.

• tldr; you can't

Linked Worktrees are tracked in the .git/worktrees directory

When you make a commit in a linked worktree, that commit is automatically reflected in the main worktree Why this makes sense:

• The linked worktree doesn't have a .git directory
• It is not a separate repository.
• It is just a different view of the same repository.

You can almost think of a linked worktree as just another branch in the same repo but with its own space on the filesystem.

  git worktree remove <worktree name>

NOTE

• This deletes the worktree: it removes the worktree directory from the filesystem
• It does not remove the branch.
• Run git branch in the main git repo and you will see the branch without the "+" prefix which a worktree will have.

Alternatively:

• Delete the worktree directory manually

• Then prune all worktrees

    git worktree prune

Naming convention for software - vMajor.Minor.Patch

• Major: breaking changes
• Minor: safe features
• Patch: safe bug fixes

It has two primary purposes:

1. To give us a standard convention for versioning software
2. To help us understand the impact of a version change: if it's safe (how hard it will be) to upgrade to

Tags are used for all sorts of reasons. Sometimes they're used to denote releases. Tags that follow semver are common.

  git tag -a v3.10.2 -m "Fixed a lil bug"