A distributed revision control system

Source code management system for software development. 

Maintaining versions of applications when these have a large number of source files.

SourceTree

SourceTree is a free Git Client that provides a graphical interface for Git repositories.

Terms

  • Repository: A repository is a collection of commits, 
  • Index or Staging Area: changes are first registered in something called the index or stage.
  • Working Tree or Working Directory: A working tree is any directory on your file system which has a repository associated with it.
  • Commit: A commit is a snapshot of your working tree at some point in time.

 

Terms

  • Branch: A branch is just a name for a commit. It’s the parentage of a commit which defines its history.
  • Tag: A tag is also a name for a commit, similar to a branch, except that it always names the same commit.
  • Master: the mainline of development in most repositories is done on a branch called “master”.
  • HEAD: refers to the last commit or branch you checked out.

 

Creating a project on github

Creating a project on github

Initializing

Clone your project locally

Initializing

Clone your project locally

First Commit

  • A. The indicator that your working copy is not clean anymore. 
  • B. These buttons allow you to stage your changes.

First Commit

Once your changes are staged, you can Commit:

First Commit

First Commit

The main SourceTree Log/Historyscreen now lists your new commit:

Branching and Merging

Branching and Merging

Branching and Merging

Branching and Merging

Branching and Merging

Fix your merge conflicts and commit before doing anything else

Branching and Merging

Once your conflict is resolved, don't forget to commit right away! 

Branching and Merging

Note how the Log/History view now shows your merge commit:

Publishing your changes: Pushing

Publishing your changes: Pushing

Before doing a Push it's important to Fetch (or Pull, see below) so that we get the latest updates from the server and merge them in with our local changes.

Publishing your changes: Pushing

We can leave the experimental branch as local-only. When you confirm the dialog, your new branch is created on Github, the commits are pushed and the result is the following:

Get the latest server updates: Fetching and Pulling

In TFS (or SVN), when you "Get Latest..." (or "Update") you risk generating conflicts with your current working copy.

 

In Git, when you Fetch from all your remotes, it is a much safer operation. All that will happen is that your local copy of the remotes' branches will be updated. It is then up to you to merge any new commits from the remote branches into your local branches.

Get the latest server updates: Fetching and Pulling

Let's continue with our example. Assume that, prior to our initial Push, we had cloned the original repo on another PC (referred to henceforth as PC2). In PC2's local repo the Log / History view looks like this (assuming gitflow was initialized):

Get the latest server updates: Fetching and Pulling

The result is that your local copy of the remote branches is updated, as shown here:

Get the latest server updates: Fetching and Pulling

To be on the safe side, try to always use Fetch before using Pull, so that you get a chance to visualize how difficult the remote-to-local merges will be.

If you decide to Pull, SourceTree will ask you which remote branch to merge into develop. Chooseorigin/develop:

Get the latest server updates: Fetching and Pulling

Your local develop branch is now up-to-date with the version on Github.

Git Workflow

Made with Slides.com