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.
- centralized (DEPRECATED): owncloud, Dropbox (~5 GB), Google Drive (~15 GB), Novell Filr
via UPassau’s ZIM (~600 MB, mounted as
- distributed: Syncthing (free and open-source, OUR CHOICE), Resilio Sync (proprietary, formerly: Bittorrent Sync)
Sourcesharing aka git
|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)|
Untested alternative: Savannah
- local gitlab
- Get a bitbucket/github/gitlab-account.
- Install the necessary software on your local computer (usually
ssh, and optionally some GUI).
- Link your local machine with your bitbucket/github/gitlab-account. (You need to generate an SSH-key and copy it to the settings.)
- 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.
- SourceTree (Mac & Windows)
- Github Desktop (Mac & Windows)
- TortoiseGit (Windows)
- GitKraken (Linux, Mac & Windos; UNTESTED)
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
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.
After the setup, your production workflow has three parts
- Get the changes from the repository. (see “Pull” below)
- Do the work
- Copy your changes to the repository so that everybody else can see them. (see “Commit & Push” below)
Pull (before editing)
- don’t touch/open the project files yet
- pull (and then close/minimize sourcetree)
- OPTIONAL read log messages
- 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)
- after you’re done working, save and close all project files
- if necessary open SourceTree
- “Vormerken”: mark all (changed) files that you want to upload (exclude temporary files like Apples … or auto-generated files like ‘Thumbs.db’)
- “Commit” with a meaningful message
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
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
- 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!
- Do this interactive 15-min. tutorial (beginner level)
- Do the tutorial on Git and Github from EuroScipy ‘13
- Here’s an exemplary workflow
- Read the intro of the documentation
- 2-page cheat sheet from github; Jan Krüger and Zack Rusin posted some pretty cheat sheets in 2007, somebody needs to check whether they’re still up-to-date #TODO
- a visualization between the five areas (stash, workspace, index, local repo, upstream repo)