Chapter_3

1 - Branches in a Nutshell

Create and checkout a new branch
Add a commit
git merge <branch> Merges the branch to the current branch
- For instance if you are currently on master and you merge a branch, you will merge those commits on top of master
fast-forward means the commit you are merging has the current commit in its history, so you can simply update the pointer
git branch -d <branch name> deletes the branch locally
recursive merge happens when you can't fast-forward
- Starts at the nearest common ancestor
- creates a new snapshot with the merge
- Does a simple three way merge
Merge conflicts
- Git pauses the merge process when it can't auto merge
- git status will list the unmerged paths that need to be manually merged
- Adds standard conflict-resolution markers to the merge conflicts
- HEAD: means the top of the branch you are merging too
  - Often the HEAD of master
- : means the data in the file you are merging from, so the feature branch
- After the conflict is fixed, remove the conflict-resolution lines, including the ='s
- git mergetool starts a graphical merge tool
  - Need to set the merge.tool config option to pick the merge tool you prefer, though it will default to something usually
- git commit finally to merge the fix, no comment is needed

git branch lists all current branches
- * points to the current branch
git branch -v shows the last commit on each branch
git branch --merged and git branch --no-merged will filter the branches to those that are or are not merged to the current branch
Deleting branches that have not been merged will result in an error message that you can override with a -D command
git branch <--merged|--no-merged> <branch name> will show you the status for branches other than the current one

Three way merging allows long lived branches without overhead
- IE Master, Develop, Next, etc branches for release management
Most all work should be in short lived topic branches
These are only local until you push them to the server

git ls-remote <remote> or git remote show <remote> lists all the references in the remote
- branches
- tags
- etc?
<remote>/<reference> refers to the remote reference, go figure
git clone -o <remote name> will clone and name the remote instead of defaulting to origin
git fetch <remote> grabs the remote info, not necessarily only the origin
git push <remote> <branch>
- this is a shortcut for git push <remote> refs/heads/<branch>:refs/heads/<branch>
git push <remote> <branch>:<branch> does the same thing
git config --global credential.helper cache sets up caching for your https username/password
After a git fetch <remote> gets you a server branch, you don't necessarily have it locally
- You need to do a git checkout -b <branch> origin/<branch> to get a local editable branch
git checkout -b <branch> <remote>/<branch> sets up tracking against the remote
git checkout --track <remote>/<branch> is shorthand for this
Even better, git checkout <branch> automatically starts tracking if
- The local branch doesn't exist
- The local branch name exactly matches the remote branch name
git branch -u <remote>/<branch> sets up tracking for a local branch you are in
@{u} or '@{upstream}is an alias to/`
- For example git merge @{u} instead of git merge origin/master
git branch -vv lists all branches and their tracking
git pull is an alias to git fetch; git merge
git push <remote> --delete <branch> delete the branch from the remote .

Rebasing allows you to take all of your commits from one branch and replay them on top of another branch
The simple example is when two branches have diverged, you can apply one branch on top of the other to get its history
Rebasing does not have a merge snapshot added to the history
git rebase --onto <branch1> <branch2> <branch3>
- Rebases branch3's commits and the common commits from branch2 onto branch1
- Use case for this is if you branched a feature branch off of master, then branched a feature branch off of the feature branch, and only want the second feature branch onto master (which will need to take any commits in the first feature branch with it)
- This will allow the first feature branch to stay separate as much as possible while getting the second feature branch onto master
git rebase <base branch> <feature branch> replays the feature branch onto the base branch
Only rebase local work, work that is pushed to the server and used by collaborators shouldn't be rebased, it gets ugly
git pull --rebase will automatically try and fix when a collaborator has rebased your commits
Rebase rewrites history, Merge shows exactly what happened. Up to your team to decide what you want your history to show (where rebasing is applicable)