Distributed Version Control

Steven J Zeil

Last modified: Oct 20, 2020
Contents:

Abstract

Distributed version controls models relax the dependency upon a central repository as the keeper of the one true project.

We will look at git, a popular distributed version control system.


Sounds Like Anarchy


A Synthesis of Local and Remote

In a distributed model, a developer maintains


Two-Level Commits

The local/remote division helps resolve a common dilemma in centralized VC systems:

A newly checked-out copy should always compile and yield a (roughly) working product.

a.k.a., “Don’t break the build!”

Matthew McCullough’s tongue-in-cheek critique: Please. Stop using Git.

1 git

1.1 Where do files live?

 

1.2 Revisions


git Snapshots

A git repository contains, conceptually, a collection of snapshots (a.k.a., commit objects, a.k.a. revisions, a.k.a. versions).

Each snapshot contains


Heads

A git repository also contains a collection of heads.

These are human-assigned names for selected snapshots.

 


How shall I name thee?

Snapshots in a repository may be identified by giving

1.3 History

Common Local History Commands

1.4 Exploration

Every Local Repository is a Branch

So one way to “branch” in git is to simply check out a new copy.

But sometimes we want to branch within a local repository


Branching Within a Local Repository


When Should I Commit? (Another perspective)

git users consider branches to be cheap.

So some advocate

Remember, every local copy of the repository a branch in its own right. So one way to achieve the same effect is to commit frequently in your local repository but only push to the central repository when you have something in a releasable state.

This approach delays making your unfinished code available to other members of your team. Whether this is a viable approach depends on


Merging Local Branches

2 Collaboration

Collaboration in git takes the form of interaction between your local repository and a remote repository.


Starting from a Remote Repository

If you are working with an existing remote repository

git clone remoteSpec

creates a new local repository as a copy of the remote one.


Cloning

 

Suppose that we have a remote repository with two branches and a few commit objects on each.

 

git branch --track enhanced origin/enhanced


Life after Cloning

 

Starting from this local repository, …

 

… suppose each repository adds a commit along the trunk:

Our local heads separate from the remembered positions of the remote ones.


Fetching Remote Changes

The basic command to get changes from the remote repository is git fetch

 

Remember, each repository is, in essence, a new (set of) branch(es)


Pulling Remote Changes

More commonly used than fetching is pulling, which combines a fetch and a merge

 

Starting with this remote repository…

 

…and this local one.

(Note that commits (F, G) have been made to both repositories since the clone was created.)

Then

git pull origin master

yields this new version of the local:

 


Pushing to the Remote Repository

The push command

 
If the remote repository looks like this

 
and our local repository looks like this

 

git push origin master

yields this remote repository.


Push is NOT the Opposite of Pull

It’s actually the opposite of fetch

This leads to an important restriction

The remote head must point, before a push, to an ancestor of the commit that it would point to after the push.


This Push Will Fail

 
If the remote repository looks like this

 
and our local repository looks like this,

because if it went through, we would lose access to a state already committed in the remote repository.

 


Avoiding Bad Pushes


Rebasing

Rebasing changes the parent relationship of the current head so that it appears to have been derived directly from some other selected head.

 
If we start with this and do

git rebase master

 
we get this.


The Perils of Rebasing

For all the talk about rebasing in the git literature, you would think it was a very common operation.

But,


Why Rebase?

Generally recommended only for


3 Eclipse Integration

The (Egit) plugin integrates git into Eclipse.

Operation is similar to the CVS and SVN plugins, except that


Eclipse, git, and a Forge

New projects:

  1. A Forge environment will create an empty repository

  2. Use the Git Repository Exploring perspective to clone the repository .

    • Store it outside your normal Eclipse workspace.
  3. Create a directory to hold the project as a sibling of the .git directory you have just obtained.

    • Put at least one file of content (e.g., a build.xml file) in that directory.
  4. In Eclipse, do File Import and select Git. Follow the instructions to name your local repository that you just cloned and “Use New Project Wizard”.

  5. When the regular project wizard starts, direct it to your project folder you created in step 3.

  6. After the new project wizard is completed, Eclipse still will not show the project as managed by Git.

    • Use Team Share project .... You’ll be asked what repository to use. Let Eclipse try to find it. (It should be able to do so).
  7. Use Team Add to index to add files to version control.

  8. Team Commit (or Synchronize).

  9. Team Push.


Existing Projects

  1. A Forge environment will contain instructions/settings on how to access the existing repository

  2. Use the Git Repository Exploring perspective to clone the repository.

    • Store it outside your normal Eclipse workspace.
  3. In Eclipse, do

    • Create a new Java project, outside of the default workspace location. For the location, navigate to your newly created copy of the project directory, within the directory where you cloned the git repository.
    • Or, for non-Java projects, File Import and select Git. Follow the instructions to name your local repository that you just cloned and use the New Project Wizard .

      When the regular project wizard starts, direct it to your

    project folder you created in step 3.
  4. After the new project wizard is completed, Eclipse might not show the project as being managed by Git.

    • Use Team Share project .... You’ll be asked what repository to use. Let Eclipse try to find it. (It should be able to do so).
  5. Use Team Add to index to add files to version control.

  6. Team Commit (or Synchronize).

  7. Team Push.


from The System