When working together, we will sooner or later produce something (hopefully). In the case of computer science, this usually means files (duh!). Several improvements have been suggested over filenames-with-counter-via-email-attachment.

Filesharing

  • centralized (DEPRECATED): owncloud, Dropbox (~5 GB), Google Drive (~15 GB), Novell Filr via UPassau’s ZIM (~600 MB, mounted as H:/)
  • distributed: Syncthing (free and open-source, OUR CHOICE), Resilio Sync (proprietary, formerly: Bittorrent Sync)

Sourcesharing aka git

public hosts

host public private size limit groups
Github oo none (edu: 5) 1 GB/repo; 100 MB/file oo
Bitbucket oo oo 1 GB/repo (soft); 2 GB/repo (hard) max. 5 (edu: oo)
Gitlab oo oo 10 GB/repo oo

Untested alternative: Savannah

private hosts

Setup

Github has its own tutorial. There is also a tutorial by BitBucket.

  1. Get a bitbucket/github/gitlab-account.
  2. Install the necessary software on your local computer (usually git, ssh, and optionally some GUI).
  3. Link your local machine with your bitbucket/github/gitlab-account. (You need to generate an SSH-key and copy it to the settings.)
  4. Clone your project.

GUIs for git

If you don’t want/like to interact via the command line, the git-webpage maintains an extensive list of GUI clients.

Field Report (git with gui on windows): Tried SourceTree at first and it worked reasonably well, but I found the interface bloated (for our purposes). Tried Windows on Git + TortoiseGit next (trade real GUI for context-menu) and found that the instructions by Adam Feber worked almost out of the box. Thanks. I just had to Shift-Right-Click to actually get/find the clone command, but that’s hopefully a one-time thing.

Production Workflow

After the setup, your production workflow has three parts

  1. Get the changes from the repository. (see “Pull” below)
  2. Do the work
  3. Copy your changes to the repository so that everybody else can see them. (see “Commit & Push” below)

Pull (before editing)

  1. don’t touch/open the project files yet
  2. pull (and then close/minimize sourcetree)
  3. OPTIONAL read log messages
  4. browse with filemanager to the directory of your project and work there

In the case of TortoiseGit, this is a right-click on the top-level folder of your project and then “Pull”

Commit & Push (after editing)

  1. after you’re done working, save and close all project files
  2. if necessary open SourceTree
  3. “Vormerken”: mark all (changed) files that you want to upload (exclude temporary files like Apples … or auto-generated files like ‘Thumbs.db’)
  4. “Commit” with a meaningful message
  5. Push

In the case of TortoiseGit, this is a right-click on the top-level folder of your project, then “Commit” -> “Msg” -> “Commit”. Followed by “Push” (and “Close”).y

Q: Why are commit and push two separate steps? A: There’s a logical and a technical reason: maybe you want to commit not all of your changes (but only some who fit logically well together); maybe you’re without internet connection (and thus can’t push), but still want to “freeze” the current state.

Best Practices

  • Don’t put (external) dependencies in version control
  • Don’t put (binary) output in version control (use GitLFS or pre-/post-commit hooks)
  • Use gitignore-files, e.g. for paper-repositories (LaTeX), code-repositories (Python), and others
  • Single Source of Truth is not a git-principle, but applies whenever you are tempted to start “just another file on the side” – Why not continue/modify a given one. It’s all version controlled!

Pro Tips

Further Reading