Rebasing

When you make a new commit, that commit is a child of the former commit in the same branch, its parent.

When you merge two branches, you move the branch pointer forward - and if there is a need for a merge commit, it will be added as a child of its two parents.

Rebasing is when you figure out that you don’t like your parents, and decide to swap them out for someone else.

Exercise 7.2: Forms of cloning

Create a new empty repo on github, call it ex72

Go to a non-git folder

git clone https://github.com/OsirisTerje/exercise23 exercise23-full
git remote remove origin
git remote add origin <your-url>

Then do a shallow clone

git clone --depth 1 https://github.com/<your account>/<your repo> exercise23-shallow

Check them out and compare them with GitViz

Now try a shallow clone on the 1GB repo from exercise 1.2, https://github.com/openshift/origin

Notice the time it takes.

Check it out with git-sizer

Exercise 7.1 : Multiple repos locally

Run Exercise-7.1.cmd from a non-git folder

DO 1

Use two instances of gitviz to check the content of the two client repos, the two server repos, and between the client and servers

Notice the way the secondary server repo is added

The exercise introduces bare repositories. Explain what that is.

DO 2

Connect the first of the client repos to a server, ofc using a different remote name

Exercise 6.2 Aliasing

Git support creating shortcuts for its commands, known as aliases.

Aliases are best put into the Global section, or even System section if you have multiple users on the same machine.

DO 1 Shortcuts

Open up the global section in your editor:

git config --global -e

Check that there is no [alias] section already

If not, add a new such section

Now, let us look at some possible nice shortcuts. I prefer very short single letter or just a few letters abbreviations as my shortcuts. YMMV, so find out first what suits yourself.

Exercise 6.1 : Configurations

Checking your configuration

Drop down to any git repository

List your complete configuration by

git config -l

You possibly got quite a long list, remember it has three levels, so you can filter it by that:

git config --system -l

git config --global -l

git config --local -l

Some configs to be aware of

Check that you have set the editor for git

Verify that the editor is being called, by doing :

Exercise 4.8 Your history is crap

You get a suspicion that the history of the repo you have contains unwanted stuff. It may be because the repo is too big, or because you say a reference to a bianry file when running git-sizer, or something gets in the way.

DO 1 Prepare

Grab the archive binthing.zip

Unzip it into a new folder. This a repo.

You check the folder that it doesn’t contain any suspicious files.

Ex 4.7 Cleaning up - Take 7 : So you pushed….

If you have pushed you can’t [should not] rewrite local history any more. If you then see one of your commits are wrong, you can revert it.

DO 1

Use the repo from 4.6. We will assume it is a repo that has a remote.

(Keep GitViz up!)

Run the following commands:

echo C4 > c4mismatch.md
git add *
git commit -m"c4"

If this was local only we could have got rid of this using git reset, but since it is pushed, we can’t. That would rewrite history.

Cleaning up - Take 5 : Getting rid of your own inadvertant mess

So you messed up - better clean it up :-)

DO 1

Use the same repo as in 4.5, recreate the same again by running the ‘Exercise-4.5cmd’

Look in the folder, and you will see three nice markdown files.

Now run

Exercise-4.6.1.cmd

Then check the status, and if you like, the content of the files.

git status

Now, this was bad, and we just want to forget about the whole thing:

Ex. 4.5 Cleaning up - Take 5 Amending

Amending

Create a new local repo again

Run Exercise-4.5.cmd

Now, look at the history using your grahical tool (Fork/SourceTree), or simply by using

git log

Also, keep GitVIz pointed at this new repo. It should show a rather nice image.

From the history view, you see that the commit message is not as you like it.

You can change the message of the last commit by amending the commit.

Ex 4.4 Cleaning up - Take 4, Pull rebasing

Before doing these exercises, ensure you have the config properly set up with merge tools.

Join up with your team, and agree upon a common repository where everyone has access. It can be one of the team members own repo, just invite in the others on the team, or some other “scrap” team project.

Assign one as the team leader, Dev0

Cleaning up, take 1, Getting the history linear

Rebasing with origin

Clone down this repo

Open up Gitviz and Fork (or whatever tool you use)

Ensure you are on master

You can see one commit in master and one in Whatever, children of the original starting commit. The branches have diverged.

• Merge in the branch Whatever

As you can see, you now have a new merge commit. We want to get rid of this and get a linear history.

Clean up - getting rid of stuff

DO 1 Cleaning out branches

A branch is just a pointer, so it doesn’t take up any space [you need to be concerned about]. But, it may clutter your view of the repo, and be annoying.

Create a new empty folder.

Point Gitviz to that folder.

Run the batch file Exercise-4.2.cmd

Go through the steps. Notice the pause steps. Use GitViz to see what happens for each step

Clean up - fixing just noise

Remote branches

DO 1 Remove local copies of remote deleted branches

Create a new repo Exercise41, locally and on the server, add a commit to it, and push it to the server.

Then create branches a,b,c and d.

Push each of these branches to the server

Run

git branch -l  --no-color

Then go to the server, and delete the branch b

Locally, go back to master,

Exercise 3b.1: Rebasing

Simple rebasing

Create a new empty local repository

Then run the command file: Exercise-3b.1.cmd, to create the basic setup

Open up GitViz on the repo

You’re now standing at the branch Experiments

Notice the tags added to mark the excisting commits.

Also, it can be wise to make screenshots of each step you do here, so that you can go back and see what really happened.

Scenario

Lets just assume that someone else did the change in the master branch. You really want your commit in the experiment branch to be based on that commit, rather than the one at “YouStartedHere”.

Pull Request with policy

DO 1

Clone NUnit.Practices

Remove the remote

Create a new repo on your Github account

Invite your team members to your repo (at least a couple of them)

Hint: Settings/Manage Access -> “Invite a collaborator” button

Assign the local repo to this new remote repo, and push all

Verify that an Action is running

DO 2 Set up a pull request policy

You are going to protect the master branch. This means that to update this branch everyone have to go through your pull request and fulfill the requirements in the PR policy.

Exercise 2.4 - Other branch types, or temporary branches

Simple stashing

You can reuse one of the former repos, or just create a new repo, add a first commit like:

echo C1 > C1.md
git add *
git commit -m"C1"

Stay on master

echo stuff > stuff.md
echo otherstuff >> C1.md

“Boss comes screaming into the room, demanding you do a hotfix right away”

Now stash your work, no time for finding out if you can add it to your branch or not, just get rid of this, so that you can switch branches.

Branching conventions

If you choose to have a complex branching structure, you can create some order into these.

Reuse on of your earlier repos, e.g. Exercise 2.1 repo

Assume you have multiple teams with many developers working on this, and you need to create a bunch of release branches, bunch of task branches, and you have a lots of bugs that needs to be handled, so you want to keep them as seperate branches too.

Exercise 2.2 Merging

A closer look at merging

Use one of your small repos, e.g. the one from Exercise 1.3.

Ensure you have GitViz open.

Ensure you are on the master branch

• Create a new branch MyTask1 and switch to it

Check that you’re actually on the new branch

• Add a file and commit it.

Notice the two branch pointers.

• Go back to master

• Now merge MyTask1 into master

Look at Gitviz again, what happened ?

Understanding branching

Simple branching

DO 1

Create a new repo

Point Gitviz to it

echo C1 >> c1.md
git add *
git commit -m "C1"

GitViz: What is the name of the branch that now just appeared?

Did you explicitly name that branch?

Run git-sizer and note the values:

Now, create a new branch:

git switch -c experiment

Run git-sizer again

What changed there?

Notice HEAD!

Note: What is HEAD

HEAD is a special kind of pointer, indicating WHERE YOU ARE with respect to your workspace

Exercise 10.1

Cherrypicking

DO 1

Create a new repo

Run Exercise-10.1.1.cmd

Look in Gitviz, and Graph tool

Find the commit SHA for the one containg C4

We want this over to the master branch, and we dont want the C3 nor the C5 there, so we will cherrypick the C4

Ensure you are on master

git cherry-pick <YourSHA>

Verify that these are the files now present in the workspace, and that the status is unmodified on all

Exercise 1.3

Git states

Init a new repo

Create two new files

echo C1 >> c1.md
echo C2 >> c2.md
git status 
git status -s

The git status gives a detailed status, while git status -s gives a short notation, with letters in the two first columns stating the states. The first column is the Stageing area status, the second column is the workspace status

The following symbols are used:

Commit the file, check the status

Exercise 1.2 - Remotes, sizing

Install a tool

Install git sizer following these instructions

Also check this blogpost

Why should repos be small and what does it mean

Start cloning this repo.

If too big, try:

cloning this repo.

Still too much?

The try this, you will manage it!

Run

git-sizer  --verbose

How does it look? Size, structure ?

Open it up with your favourite UI tool, how does that work ?

Look at Blobs/Total size. How does that compare to Explorer’s size of the repo ?

Exercise 1.1: Ensure you’re all set up correctly

Tools

Check git on command line

You should have git itself installed, and available on command line.

If not Install Git

The Git documentation can be found here: https://git-scm.com/docs

Open a command prompt, and run:

git --version

You should see version 2.25 or higher for Windows, 2.23 or higher for Mac. If not, download it

First check your configuration

git config user.name
git config user.email

If nothing, then configure it with

Demo 2.5

1

git init
echo c1 > c1.md
git add *
git commit -m"c1"

2

git switch -c work

3

echo cc >> c1.md
git add *
git commit -m"c1"

4

git switch master
git merge work
git switch work

Go back to 3

Alternative:

Do #3 5 times, then do #4

Configurations for Diff and merge tools

Possible diff/merge tools

Default is vimdiff.

Some alternatives that are understood by git

• KDiff3
• BeyondCompare

These have to be installed, and available in the path.

Run

git mergetool --tool-help

to see a complete list of supported tools.

An alternative that must be fully configured:

• Visual Studio (vsdiffmerge)

An alternative that has built in support

• Visual Studio Code

See information here.

Note: Get to this by using the Source Control tool, select the file(s) shown under “Merge Changes”.

Short recipes for different types of branch creation and removal

Set up local branches for all remote brances

git for-each-ref --format='%(refname:strip=3)' refs/remotes | grep -v master | xargs -L 1 git switch

Delete all local branches, but not master

git for-each-ref --format='%(refname:strip=2)' refs/heads | grep -v master | xargs git branch -d

Alternative: Delete only local branches that have been merged to master

git branch --merged master | grep -v master | xargs git branch -d

Delete all remote tracking branches except master

git for-each-ref --format='%(refname:strip=2)' refs/remotes | grep -v master | xargs git branch -rD origin

Delete all remote branches except master

git for-each-ref --format='%(refname:strip=2)' refs/remotes | grep -v master | xargs -L 1 git push -d origin 

Delete a subset of local branches

Assume they are arsting with bugs

Example of a branching/merging/rebasing story

Developer 1

First change something on the remote branch ‘update’ twice

git pull

Change something on remote branch master and pull again

Now merge doing a rebase and fast-forward merge on server, and the a pull again

Another developer (Dev 2) already had a clone of the repo - before the rebase/merge done, and he creates a local branch from origin/update, then add a change there.

Branches Deep Dive

We learned that a branch can be a local branch or a remote branch.

The local branch lives in your local repository, and the remote branch lives in the remote repository.

Then we have tracking branches.

A tracking branch is a local specific that contains the binding between your local branch and a given remote branch. Another name for tracking branch is upstream branch.

Trap: You can’t work locally with a tracking branch.