Skip to content. | Skip to navigation

Personal tools

Sections
You are here: Home / Developer / Repositories / Simplest use of Git for working together

Simplest use of Git for working together

If you do not know anything about Git, but are working with someone experienced in Git, then this simple scenario may help you.

Below we assume a collaboration of two persons, who aim to write text or code together, irrespective of whether in LaTeX or C++ or Evolvix InfoBlocks. Meet:

Alice, the 'Git-person', knows more about Git, can merge different version variants as needed, can set up a new repository for collaboration on a gitolite server, and basically knows how to resolve any Git-complications (either directly or by getting help). We assume below that she has already set up a repository for writing ProjectX together with Bob. 

Bob, the 'Non-Git-person', is expected to know nothing about Git, nor version control systems, distributed or otherwise. This page here explains in a nutshell the basics that Alice will need to convey to Bob in order to get the collaboration started. Here we assume that Bob has completed the following steps:

  • Get SourceTree: Both will access Git by using a program called "SourceTree", which presents a Graphical-User-Interface to users and produces for them in the background the rather arcane Git commands required for interfacing with the Git repositories on a server that runs a program called 'Gitolite'. SourceTree comes with a local copy of Git bundled inside and is currently the easiest way to get started with Git. It can simply be downloaded from http://www.sourcetreeapp.com/ and then only requires registering an account with Atlassian in order to receive a free license.
  • Generate and submit their public ssh key: ProjectX is currently developed in a so-called 'EnclosedEffort' ('EE') repository to facilitate experiments not meant to become part of publicly released code (hence reducing confusing complexity). To distinguish between Bob and Alice, as recognized contributors to ProjectX, and everybody else, we need some electronic key that is necessary for access. Since passwords are cumbersome and relatively insecure, we use the OpenSSH public-private key infrastructure. It allows you to generate a public-private key pair of which Gitolite on the ProjectX server will only need to know the public key of anybody who is supposed to get access. We use Gitolite, a server-side program, to provide developers with secure access to the corresponding repositories and without the need to enter a password. Gitolite requires a public ssh key from each contributor like Bob, who will thus need to submit that key to Alice, who will make the necessary arrangements. Please follow these instructions for how to generate your public ssh key and submit it.

Before we discuss how Bob and Alice collaborate, lets describe the basic repository setup.


The Basic Repo Setup

Let's define this double arrow A <====> B to be a two-way communication channel between two endpoints A and B. Then our basic repo setup can be described as follows:

 

AliceGitRepo on AliceComputer  <=====>  Gitolite (using Alice's Public Key)  <=====>  GitRepository on ProjectX_RepoServer

 

BobGitRepo on BobComputer  <=====>  Gitolite (using Bob's Public Key)  <=====>  GitRepository on ProjectX_RepoServer

                                                                  

Each of these repos can have a number of branches, each of which is a sequence of commits. Each commit saves a bundle of changes to files in ProjectX that will be stored and versioned. They can be transmitted between repositories by operations like "pull" and "push". For example:

  • Bob can push his latest commits that are stored in his local BobGitRepo on BobComputer up to the GitRepository on ProjectX_RepoServer.
  • Alice can pull Bob's latest commits that are stored on the GitRepository on ProjectX_RepoServer down to her local AliceGitRepo on AliceComputer.

To avoid chaos, all communicating repositories will need to have the following three branches to which the corresponding commits are added during push/pull operations:

  • Bob_CommitBranch_ForAllToPull: Bob should always commit to this branch and should not commit to other branches to make it easier for Alice to track Bob's contributions. Thus, at the beginning, before Bob's first commit, Bob will need to use the SourceTree GUI to "switch" to this branch (assuming that Alice has already put it in place).
  • Alice_CommitBranch_ForAllToPull: Alice will only place commits on this branch that are safe for Bob to pull. Other branches that Alice may need to organize her work will have different names and should not be pulled by Bob. Alice will regularly incorporate Bob's latest additions in her branch, so that Bob can easily and regularly pull the latest recommended changes from this Branch.
  • master: This branch is provided by Git out of the box and is used for initializing a new repository that has been just cloned. Alice commits to this branch the latest progress that she would want  anybody to see, who just joins the project.


How to work with the Basic Repo Setup

Once all the branches above are set up, and Bob has switched his repo to the Bob_CommitBranch_ForAllToPull branch, then Bob can type away and happily commit without worry. A recommended routine for Bob would be to:

  • Commit at the end of each work-day and after reaching any significant milestone. Commits should have a comment line on what progress was made.
  • Push the commit up to the server, in order to have a backup and to allow Alice to follow the project.

Other instructions below may help with setting this up or with special cases that may show up on Bob's or Alice's end.

 



Background

This very simplest Git use-case serves as a foundation. We developed this extraordinarily simple Git workflow for a scenario, where someone with absolutely no Git experience writes code together with someone who also commits to the same repository and has sufficient experience to merge code as needed. Feel free to adapt these instructions for your own needs. Let us know if you see improvements; the insights learned from this example were foundational to various ideas we are developing on how to simplify in Evolvix how non-computing biologists might use Git.

 

Configuring SourceTree

Open SourceTree, and go up to the Mac Menu Bar at the top of your monitor. Select SourceTree -> Preferences..., and the Preferences dialog will appear. Switch to the Git tab, at the top of that dialog, and uncheck the check box for "Use the Staging Area".

 

Seeing Invisible Files on the Mac

To show invisible files you need to change that setting in the system and then quit Finder to allow the new setting to take place.

To make all files visible (you may need the 2nd one with the small "finder" on Mountain Lion OSX10.8):

defaults write com.apple.Finder AppleShowAllFiles TRUE

defaults write com.apple.finder AppleShowAllFiles TRUE

You need to quit Finder for this to take effect. If you do that only once, kill the Finder in the app monitor or use

killall Finder

more often, you can add that to the menu:

 

How to quit finder as explained here http://lifehacker.com/333819/add-quit-to-the-finder-menu  

Enter: at the command line:

defaults write com.apple.Finder QuitMenuItem 1