Essential Git for Scientists
  • Introduction
  • Basic Concepts
    • Version Control
    • Git
    • Repo
    • Commits
    • Branches
    • Remotes
    • GitHub
    • De-centralisation
    • Summary
  • Basic Operations
    • Install Git
    • Create a Repo
    • Make a Commit
    • Inspect a Previous Commit
    • Revert a Change
    • Make a Branch
    • Extend a Branch
    • Fast-forward merge
    • Resolve conflicts
  • Intermediate Concepts
    • Commits
    • Three Trees
    • Rebase
    • Fetch
    • Pull
    • Push
  • Advanced Concepts
    • Reset
    • Interactive rebase
    • Formatted patches
    • Blame
    • Stash
    • Log filter
  • Cookbook
    • Undo
    • Branches
    • Diff
    • Stash
    • Merge
    • Hooks
    • Squashing
    • Rebase
    • Interactive Rebase
    • LFS
    • Submodules
    • Remote
    • Force push
    • Identify merged branches
    • Formated patches
    • Apply patches
    • Interactive rebase
    • Squash commits
    • Pull rebase
    • Log
    • Blame
    • Biset
    • Reset
  • Exercise
    • Exercise 1
    • Exercise 2
Powered by GitBook
On this page
  1. Basic Concepts

Version Control

When I was writting my first journal article, as many of others, I used file names to indicate its version. I had a manuscrip.docx as the beginning draft, sent to other coauthors to review, included the comments and ended up as manuscript_v2.docx. Typically, this will end up as manuscript_final.docx, which you wish to be the last version.

A typical roadmap for saving your files is shown below.

manuscript.docx
manuscript_v2.docx
manuscript_v3.docx
...
manuscript_final.docx

In reality, this list goes on.

manuscript_final_v2.docx
manuscript_final_v3.docx
...
manuscript_final_never_change.docx
...

This is a live form of version control, despite being in a very inefficient way.

If you only have two or three versions it's probably fine. However, the drawbacks are quite obvious:

  • You have multiple copies of the same document in the same folder.

  • Only you remember (hopefully) what has been done. It's hard to include others to collaborate.

  • It's hard to know easily which one contains what changes.

  • It lacks clarity on why you've made certain changes.

  • There's no rules to protect the history, e.g. you could save a change in a previous version by accident.

In addition, this will quickly become unmanagable when there are associated files (like experiment data) for each version.

There's a much better way.

PreviousIntroductionNextGit

Last updated 1 year ago