Welcome to Part 3 of this review of the Pluralsight course Using Git with a GUI by Xavier Morera.

Xavier is an entrepreneur, project manager, technical author, trainer, Certified Scrum Professional & Scrum Master and Certified Microsoft Professional and Microsoft MVP.

He has spent a great deal of his career working on cutting-edge projects with a primary focus on .NET, Solr and occasionally iOS. He’s also a fellow Simple Programmer blogger.

Also in this series:

Part 1 – The Case for Git with a GUI
Part 2 – What You Need to Know about Git
Part 3 – Mechanics of Using Git
Part 4 – Git to the next level

Mechanics of Using Git (With a GUI)

Xavier introduces this as a must-watch module for anyone serious about using Git, and promising “More Bang For You Buck”.

What this means is here we learn the most commonly used Git functionality

Quick Tour

How to:

– See all branches or the current branch
– View branches in date Order to ancestor order
– Blame Selected
– Open Current Version
– Open Selected Version
– Show in Explorer
– Copy Path To Clipboard
– File menu options (Clone and Registration)
– View menu options
– Repository menu options
– Actions menu options
– Tools menu options
– Help menu options
– Use shortcut keys
– Use toolbar actions
– Use workspaces
– Search

Xavier also explains what seven different Icons mean, and briefly runs through the each of the tabs in the Options menu.

Mercurial isn’t covered in this course. For information on that there are a few options:

Mercurial Fundamentals by Tood Ropog
Meet Mercurial by Dan Benjamin
Practical Mercurial by Rob Conery

Getting the Code

1. When we want to contribute to an open source project, we fork a repository.
This creates a full copy under your own GitHub username.

2. We clone the repository from the cloud to our local repository.

3. Checkout or create a new branch (exceptions are covered in the branching strategies module)

For Forking, we see an example using one of Xavier’s favorite projects.
Mauricio Scheffer’s SolrNet is a Solr client for .Net and a project that Xavier contributes to.

We see how easy it is to fork this project.

We have seen the Clone / New window earlier on in this course, but we learn it in more detail here.

We have seen the Clone / New window earlier on in this course, but we learn it in more detail here.

As Bitbucket and SourceTree are created by the same company, they have integrated these products with each other.

Bitbucket has a Clone in Source Tree button, and we see that when we click on this Google Chrome makes an external protocol request.

Clicking “Launch Application” launches Source Tree with the correct clone from location.

Xavier also covers staying up to date, describing Fetch and Pull:

Fetch
– Get remote changes into local respository
– Doesn’t affect our code
– No merge takes place
– Allows us to inspect before merging

Pull is a Fetch plus a merge
– Changes into working copy
– Local branches are updated

In case this isn’t clear, Xavier shows a diagram of our remote, local and working copies.

We fetch from remote to local, and merge from local to working copy.

A pull goes from remote to our working copy.

Demo: Getting the Code

On GitHub, Xavier creates a fork from SolrNet, and copies the URL for cloning.

Then in SourceTree, he opens the Clone Repository dialog, pastes the URL into “Source Path / URL” and sets the Destination Path.

SourceTree displays “Repository Type: This is a Git repository” Cloning takes a few minutes for this project, as there are 944 files and many commits.

We then see that we have the full commit history for this project, and that we are viewing our master branch.

There is also an origin dropdown underneath Remotes on the left hand side of SourceTree.

If we open this, we see all of the branches that have been pushed into the original repository.

Branches

Xavier describes branching as Git’s killer feature.

Or more specifically, the ability to have multiple branches and merge easily. We can work on multiple features or bugs at the same time without interfering with one another.

Demo: Branching

We create two different branches:
1. From the working copy parent
2. From a specific commit

We see how to commit a change to the one of the project documentation files: “This is a test branch”

Then we switch branches and commit a different change to the same file: “This is a commit in the other branch”

This file changes as we switch from one branch to the other.

We can also check out remote branches and get a snapshot of the code in that commit.

Code Is Ready – Now What?

There are three things we can do with our code changes:

• Committing: saving changes into our repository, including a log message
• Stashing: save changes for later so we can reapply them when we need them
• Discarding: reverting our changes back to the original state. Things didn’t work out
• Each file has three states: Modified/Untracked: modified means changed and untracked means it’s a new file
• Staged: Marked for next commit.
• Can stage hunks and take the change to the staging area. Committed: Changes stored in the repository Xavier also discusses the sections of a Git Project: Working Directory, Staging Area and .git Directory
• Finally, we learn about preparing for the commit, and the index.

Coding with Stashing and Discarding

Discarding changes is a destructive operation.

We can discard simply by right clicking on an uncommitted change and choosing Discard.

This brings up a dialog which says “Click ‘Reset All’ to abandon all local changes, including all file changes and also all merge status metadata.

Stashing is like a shelveset in TFS.

Stash is one of the main toolbar options, and it brings up a dialog where we enter a name for our stash (e.g. “My first stash”) and click OK.

The changes are no longer present in our repository, but there is a new Stashes section with the icon “On master: My first stash”

How do we reapply the changes we’ve stashed? We see that next.

Demo: Discarding and Stashing

Xavier shows us how to stage a change, stash it, and reapply it.

We also see how to discard changes with Reset All. We’re back to seeing our file how it was before.

Ignoring Files

There are four different ways of ignoring:

1. Exact name
2. Pattern
3. Path
4. Extension

We can also specify to ignore settings in this repository, or all repositories.

Demo: Ignoring Files

First we look at SolrNet’s existing .gitignore file and see many directories listed in here.

If we remove everything from this file, we see a lot of files appear in the Unstaged files list.

We see that SourceTree’s Ignore dialog has a useful “Ignore everything beneath” dropdown

Staging and Hunks

One differentiator between Git and other source control systems is the ability to pick and choose individual changes (hunks), from the same file.

Demo: Staging and Hunks

We see how to stage hunks and discard hunks

Commit Messages

Xavier stresses the importance of good commit messages and gives some guidelines on how to write them.

He recommends reading http://chris.beams.io/posts/git-commit/ for thorough information covering all aspects of good commit messages.

In summary the 7 rules of a great Git commit message are:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 character
7. Use the body to explain what and why vs. how

We see an example git commit from Chris Beams which follows all of these rules.

Commit

A commit is when we save the staged snapshot to the project repository.
We see some of the commit options available in SourceTree here.

Demo: Commit

We do a commit on a change that is already staged, and then amend the commit.
This involves staging the second change, and then commiting it.

A second commit is not created. Instead, the changes are added to the first commit.

Merging

Merging is when we join two or more development branches.

Xavier warns that it is our responsibility to avoid conflicts.
We should pull first to fetch and merge into our branch.

Then we can either merge our branch or do a pull request.

Demo: Merge

Branching needs merging.

In this demo we see two branches, NewDocumentation and TestDocumentation and Xavier shows us how to merge one into the other:
by checking the option “Include messages from commits being merged in merge commit” and clicking OK to merge.

GitGraph shows us they have now been merged into one branch.

There is an alternative to a merge commit: a rebase. This involves checking the option “Rebase instead of merge (WARNING: make sure you haven’t pushed your changes)”

Rebasing has some downsides that aren’t discussed here, but Xavier covers it in more depth in the next module.

Also see http://ryantablada.com/post/the-dangers-of-rebasing-a-branch
and https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Finally, Paolo Perrotta has produced the Pluralsight Course How Git Works  which has a module on Rebasing that may be worth checking out.

Push

The push operation uploads our changes to a remote repository.

It is possible to configure Git on the server side to respond to events using hooks, but that’s beyond the scope of this course.

Demo: Push

We create new a file and save it. We see the uncommitted change in SourceTree at the top of the list. We click the commit button.

On the commit screen we check the box “Push changes immediately to origin/debug-explain”

Conflicts

When there are changes in the same area in different branches, or we edit a file that is deleted elsewhere, there’s a conflict.

Xavier describes a couple of ways to resolve them:
1. Mine or theirs
2. Resolve manually

Demo: Conflicts

Xavier usually uses WinMerge as an external diff tool and Beyond Compare as a merge tool, and here we see an example of using these with SourceTree here to resolve a conflict.

Pull Requests

Xavier calls this “Here’s my code, please take it”. It’s a method of submitting code to a project that’s using distributed source control (e.g. Git).
Team members can then review changes, collaborate and improve the code. A pull request is either accepted or rejected.

If you want to do a Pull Request after forking, you must be in sync with the original repository. Resolve any conflicts first.

We see an example of how this is done: adding Remote, choosing the host type, pulling and committing.

Next we see how to open a pull request from GitHub. There’s a big green “Create pull request” button, and clicking this shows us the changes we’ve made.
If we’re happy with them we click “Open a pull request”.

On the Open a pull request screen, we include the subject and explanation and click the green “Create pull request” button.

The project maintainer gets notified and will either accept or reject the changes after he or she has reviewed them.
The pull request also has a section where other contributers can add comments and questions.

Demo: Pull Requests

The process we see is as described earlier, but this is a live demo as opposed to screenshots that we saw earlier.

Cleaning Up

Xavier advises deleting branch after merging and talks through a possible scenario.

Demo: Cleaning Up

In this demo we have two branches:
1. Pending_Changes
2. TestDocumentation

There are uncommitted changes in the Pending_Changes branch.
We see that we cannot delete a branch with these uncommitted changes when we are currently working on it.
However when we are working on the TestDocumentation branch, we are allowed to delete the Pending_Changes branch.

We also see how to rename branches in this lesson.