Git, GitHub & GitKraken

Context

With the increasing amount of data available and the increasing complexity of statistical analyses, nowadays a PhD in ecology often requires programming skills. Coding comes with challenges to be tackled to do science and good practices to be mastered to do reproducible science.

Git is a powerful tool that keeps track of earlier development stages of their code, it also ease the team work on a specific project. Technically speaking, is a Distributed Version Control Systems (DVCS): every contributor has his one copy of the code, its complete history and comes with powerful tools to version your code, create branches, compare versions and branches, etc.

GitHub is a set of web-services built on the top of . Basically, when we use GitHub:

  • one version of our code and its history is stored on GitHub’s servers;
  • we benefit from the a nice visual of GitHub pages that makes the online navigation throughout our project quite comfortable (if the repository is public everyone can do so);
  • we can readily use a ton of web-services to improve our workflow, for instance, this website is checked by Travis that also deploys the website on a gh-page.

Note that there are many GitHub alternatives, some of them such as Gitlab let you deploy the full set of web-services it provides on your own server. For instance, Debian’s packages are now hosted and maintained on a Gitlab’s server called Salsa.

As introduces several concepts (stag, stash, commit, pull, push, branch, etc.) it could be quite challenging for beginners, that is why going through a tutorial or reading a book on the topic is rather desirable. Also, using a Graphical User Interface (GUI) to visualize commits and branches could be very helpful, that’s why GtKraken had become quite popular among developers.

A Simple Git + GitKraken + GitHub Workflow

Below is the basic workflow that was presented during the two Git lab meeting lead by Gabe (24/10/2018) and Chris (30/01/2019):

  • Initialize a new repository (repo) on GitHub
  • Clone the repo to your local machine
  • Add some files / folders using your operating systems file browser
  • list files that should not be versioned in .gitignore
  • Make a commit
    1. Stage files to include in the commit
    2. Optional: ignore some files / folders that should not be checked in to commit
    3. Add a commit message (don’t be that person that leaves this blank), short – tweet like summary of what has changed. Good for looking back at the history of the project
    4. Push the commit back to GitHub (sync your local version with the version on GitHub)

Notes/comments: