Git Notes

Set and retrieve username and email:

git config --global user.name "your name"
git config --global user.email "your@email.com" 

Check using

git config user.name
git config user.email

See git status

git status

Viewing git logs in the terminal

git log 

Shows a log of all commits

Tweaks for concise log output

git log —pretty=oneline —abbrev-commit

or

git log —oneline —abbrev-commit

Create a git repo

git init

git tracks nested folders. Do not initialise a repo inside another repo. You can check this by running git status inside the folder you want to track before running git init.

Staging changes

Commits should ideally be be grouped/staged with

git add <file1> <file2>

To stage all changes, use

git add .

git add tells git to start tracking * newly added files * files that were not previously tracked (or deleted files?) * files that are modified! in the working folder.

This puts the files in a “staging area”

Committing to a repo

A commit is * not the same as a save on an individual file * can be thought of as a collection of changes that have been saved

The .git folder is the actual repository. A git commit changes the .git folder

git commit -m <commit message summarising changes>

Use this -m flag to avoid vi jail hell :)

After a commit (assuming all changes to tracked files are committed), git status will return a “working tree clean, nothing to commit” message

N.B. To both stage and commit, use

git commit -a -m <commit message>

Commit Message Best Practice?:

Git recommends using “present tense imperative style/mood” for commit messages

e.g. make a do b, rather than “This change makes…”, or “ I made…”

Atomic git commits

The idea that git commits should focus on a single feature, fix or change

.gitignore

Always exclude Secrets/API keys etc .DS_Store on Mac Log files Dependencies and packages (node, python modules etc) - can be rebuilt easily

N.B to exclude a directory, remember to include then/ at the end of the directory name. Without the / git will think it is a file.

Remember to track the gitignore file :)

gitignore.io is a repository of representative gitignore templates.

To make a change to the most recent commit

make additional change e.g. git add <> git commit —amend

Only works for most recent commit

List branches of a repo

git branch

The active branch is highlighted with a *

Create a branch

git branch <newbranchname>

This command creates a new branch based on the current HEAD. In other words, the new branch points to the same location (technically the same commit) as the current HEAD

Creating a branch does not switch you that branch

Switching to a branch

git switch <branch name> 

or use the older style less preferred equivalent

git checkout <branch name> 

git checkout is also used to restore working tree files

Create and switch to a new branch in one step

git switch -c <branch name> 

or

git checkout -b <branch name>

Branch switching nuances

Nuance 1

• If
  • there are files that only exist in the current branch and we want to switch to another branch
• Then
  • the new files will be carried over to the branch we switch to
• Because
  • There will be no conflict between the branches

Nuance 2

• If
  • there are files that exist in both the current branch and in a branch we want to switch to
• Then
  • Changes in the current branch must be commited (or stashed?) before switching to a new branch.
• Else
  • Any uncommited changes will be LOST!
• Because
  • The files will be in conflict between the two branches

Deleting a branch

git branch -d <branchname>

This command requires that * we are not on the currently checked out branch i.e. HEAD must not be pointing at * changes in the branches we want to delete are fully merged

Deletion can be forced with -D flag

Renaming a branch

We will need to do this when using github, to rename the “master” branch in git land to “main” branch in github land

git branch -m <new name>

This command requires that we are IN (or On?) the branch we want to rename!

What is HEAD?

• Think of Head as an analogue of a tape head. It points to what is current location that is being read. So if HEAD is pointing to master, this means that the master branch is being read.

What is detached head?

• Detached HEAD is when head is not pointing to a specific branch but to a specific commit.
• Useful for example to check the status of a repo at the point that a specific commit was made

Merging branches

Master/main is (usually) considered the source of truth/most important etc etc Changes are carried out in “Feature branches” and commited into master when stable

N.B. * Branches are merged. Not commits * Always merge to the current HEAD branch

Merging Worflows: Fast Forwards Commit

Workflow for simplest type of merge (a fast forward merge - where no changes have been made to the master branch, since the feature branch was created.):

• If
  • you want to merge to master
• Then
  • switch to master (so HEAD points to master) and
  • git merge

Now * Head will point to tip of * master and at this point in time. * The still exists! * From this point on further changes can be made to the feature branch and the whole process can be repeated

In a fast forward merge, HEAD essentially catches up with the feature branch. This assumes that no changes were made on the master branch

Merging Worflows: Merge commit

This is done (by git) when master has additional changes since the feature branch was created.

• If there are no conflicts between the new tip of master (where HEAD points to) and the , git can “merge” the 2 branches. The new commit now has 2 parent commits.
• The log for the master branch will show commits from both master and the

If completely new files are added, this is not a conflict

• If there are conflcits e.g.:
  • file modified in one branch and deleted on the other
  • there are changes to the same file, and at identical locations in those files.
• Then
  • human needs to resolve the conflicts!

N.B. It is not necessary to merge master and a 2 sepaarte feature branches can also be merged.

Stashing

Allows user to “stash” changes in a branch without commiting it. This is useful in scenarios where a user may need to switch to another branch where there are potentially conflicting changes. Switching to the new branch in this scenario will mean that changes in the feature branch are overwritten

Stash puts the changes away, and reverts the changes in the working copy. It will be possible to return to those changes later.

git stash 

or

git stash save

Revert the stash by using

git stash pop

git stash apply

* allows for changes to be applied while not removing it from the stash. This can allow for the stash to be applied to multiple branches.

Rebasing:

To avoid cluttering git log with multiple merge messages (to keep your local repo in sync with master you will be merging main into your local repo frequently) rebase can be used

This rewrites history, so that your feature branch has a new base at the tip of the current main branch (rather than at the point that the feature branch repo was branched)

never rebase if your code has been shared with others (i.e. do not rebase hisotry that other have) This could result in different versions of history on different repos.. and can be very difficult/annoying for users to make sense of

Never rebase the master branch!

git rebase -i HEAD "number of commits"

* i is for interactive

Git Workflow to track changes between local and remote repositories

git status

will show status relative to the current information in the local repo. Remote may have moved

git FETCH <remote> <branchname>

will fetch changes on remote to the local repo but will not update your working directory

git status

after git fetch, git status may show updated information

git checkout <branchname>

to view changes (note HEAD will be detached). Working directrry will not be updated.

git pull

to retrieve changes from remote changes will now pulled to working directory (to the working branch on the local repository)

git pull <remote> <branchname>

is a combination of a Fetch and a Merge

Fork and Clone workflow

• Fork a public repo
• Clone and work on it independently
  • Cloning automatically adds your fork as the remote repository (origin)
• However, you will likely want to be informed of changes in the original (upstream) repository. If so, you should add a second remote (upstream) pointing to the original repo that was forked

To get the changes from upstream to the forked repo

git pull upstream main

i.e. pull from upstream to main

To request original project to incorporate changes from our feature branch:

git push origin main (i.e. push changes to forked repo)

Then make a pull request to the upstream repo

Adding upstream if required

git remote add upstream <original repo url>

Changing the remote url

If the remote url is moved/renamed, the change can be made locally

git remote set-url origin <new url>

Links

gitignore.io