Working with multiple remotes

Distributed versus centralised

Older version control systems (cvs, svn) were "centralised"; the history was kept only on a server, and all commits required an internet.

Centralised Distributed
Server has history Every user has full history
Your computer has one snapshot Many local branches
To access history, need internet History always available
You commit to remote server Users synchronise histories
cvs, subversion(svn) git, mercurial (hg), bazaar (bzr)

With modern distributed systems, we can add a second remote. This might be a personal fork on github:

In [1]:
import os
top_dir = os.getcwd()
git_dir = os.path.join(top_dir, 'learning_git')
working_dir=os.path.join(git_dir, 'git_example')
In [2]:
git checkout master
git remote add jamespjh https://${GITHUB_TOKEN}@github.com/Giovanni1085/github-example.git
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Switched to branch 'master'

Check your remote branches:

git remote -v

We can push to a named remote:

In [3]:
%%writefile Pennines.md

Mountains In the Pennines

* Cross Fell
* Whernside
Writing Pennines.md
In [4]:
git commit -am "Add Whernside"
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:

nothing added to commit but untracked files present
CalledProcessError                        Traceback (most recent call last)
<ipython-input-4-892653cd7911> in <module>
----> 1 get_ipython().run_cell_magic('bash', '', 'git commit -am "Add Whernside"\n')

~/virtualenv/python3.6.3/lib/python3.6/site-packages/IPython/core/interactiveshell.py in run_cell_magic(self, magic_name, line, cell)
   2321             magic_arg_s = self.var_expand(line, stack_depth)
   2322             with self.builtin_trap:
-> 2323                 result = fn(magic_arg_s, cell)
   2324             return result

~/virtualenv/python3.6.3/lib/python3.6/site-packages/IPython/core/magics/script.py in named_script_magic(line, cell)
    140             else:
    141                 line = script
--> 142             return self.shebang(line, cell)
    144         # write a basic docstring:

<decorator-gen-109> in shebang(self, line, cell)

~/virtualenv/python3.6.3/lib/python3.6/site-packages/IPython/core/magic.py in <lambda>(f, *a, **k)
    185     # but it's overkill for just that one bit of state.
    186     def magic_deco(arg):
--> 187         call = lambda f, *a, **k: f(*a, **k)
    189         if callable(arg):

~/virtualenv/python3.6.3/lib/python3.6/site-packages/IPython/core/magics/script.py in shebang(self, line, cell)
    243             sys.stderr.flush()
    244         if args.raise_error and p.returncode!=0:
--> 245             raise CalledProcessError(p.returncode, cell, output=out, stderr=err)
    247     def _run_script(self, p, cell, to_close):

CalledProcessError: Command 'b'git commit -am "Add Whernside"\n'' returned non-zero exit status 1.
In [5]:
git push -uf jamespjh master
Branch 'master' set up to track remote branch 'master' from 'jamespjh'.
To https://github.com/Giovanni1085/github-example.git
 + 7663bfb...6aca2a7 master -> master (forced update)

Referencing remotes

You can always refer to commits on a remote like this:

In [6]:
git fetch
git log --oneline --left-right jamespjh/master...origin/master
< 6aca2a7 Add github pages YAML frontmatter

To see the differences between remotes, for example.

To see what files you have changed that aren't updated on a particular remote, for example:

In [7]:
git diff --name-only origin/master

When you reference remotes like this, you're working with a cached copy of the last time you interacted with the remote. You can do git fetch to update local data with the remotes without actually pulling. You can also get useful information about whether tracking branches are ahead or behind the remote branches they track:

In [8]:
git branch -vv
  gh-pages 6aca2a7 [origin/gh-pages] Add github pages YAML frontmatter
* master   6aca2a7 [jamespjh/master] Add github pages YAML frontmatter

Hosting Servers

Hosting a local server

  • Any repository can be a remote for pulls
  • Can pull/push over shared folders or ssh
  • Pushing to someone's working copy is dangerous
  • Use git init --bare to make a copy for pushing
  • You don't need to create a "server" as such, any 'bare' git repo will do.
In [9]:
bare_dir=os.path.join(git_dir, 'bare_repo')
In [10]:
mkdir -p bare_repo
cd bare_repo
git init --bare
Initialized empty Git repository in /home/travis/build/alan-turing-institute/rsd-engineeringcourse/ch02git/learning_git/bare_repo/
In [11]:
In [12]:
git remote add local_bare ../bare_repo
git push -u local_bare master
Branch 'master' set up to track remote branch 'master' from 'local_bare'.
To ../bare_repo
 * [new branch]      master -> master

Check your remote branches:

git remote -v

You can now work with this local repository, just as with any other git server. If you have a colleague on a shared file system, you can use this approach to collaborate through that file system.

Home-made SSH servers

Classroom exercise: Try creating a server for yourself using a machine you can SSH to:

ssh <mymachine>
mkdir mygitserver
cd mygitserver
git init --bare
git remote add <somename> ssh://user@host/mygitserver
git push -u <somename> master

SSH keys and GitHub

Classroom exercise: If you haven't already, you should set things up so that you don't have to keep typing in your password whenever you interact with GitHub via the command line.

You can do this with an "ssh keypair". You may have created a keypair in the Software Carpentry shell training. Go to the ssh settings page on GitHub and upload your public key by copying the content from your computer. (Probably at .ssh/id_rsa.pub)

If you have difficulties, the instructions for this are on the GitHub website.