Recent Changes - Search:







edit SideBar


To do


Future workshops

Librarians - spring 2016?

Tentative focus: cleaning messy data.


Data sources:

Artists - with site3, 2016?


General reference

Make changes to swc main sites

A note on branches:

  • the gh-pages branch is the "release" branch for the live website - released by swcarpentry gurus every once in a while
  • the master branch is the bleeding edge, where all changes are merged to - when a set of changes have been accumulated and checked for consistency, they are pushed to gh-pages.

What to edit and how to make files:

  • look into the existing directories. If there are only .md (Markdown) files, those can be safely edited and then submitted through a pull request
  • if there are .ipynb (iPython Notebook) files (e.g. Python and SQL lessons):
    • do not modify the .md files directly
    • instead, edit the .ipynb
      • to do this, run ipython notebook in the repository where the files to be edited are
    • once it's done, run make ipynb
      • this requires some extra packages
      • it helps to have homebrew (on Mac OS X) and pip
      • make sure you have a recent version of ruby: brew install ruby
      • then install jekyll and stuff, this should work: gem install github-pages
      • if make complains that yaml cannot be found: @@pip
      • runmake check to ensure that all is setup


This assumes that the swcarpentry/site or swcarpentry/bc repo has already been forked - if not, do so on GitHub. Only needs to be done once per user.

  1. clone the repo locally if not already done (can be done in the GUI)
  2. make sure current version of local repo is up to date with swcarpentry master: Syncing a fork
  3. create a new branch from master to hold the new edits, either with the GUI or with git checkout -b new-branch-name
    • if editing on someone else's repo (e.g. drafting a blog post together), add that repo as a source with e.g. git remote add Username
    • pull in that person's changes on the local repo using git pull Username their-branch-name
  4. make edits
  5. git add the modified file(s) and git commit with a message
  6. git push origin new-branch-name to push the edits to MY repo
  7. on GitHub, create a pull request
    • by default, the pull request will be to the main swcarpentry repo - if pulling to someone else's repo, click edit and choose their repo as destination
  8. submit the pull request

Create a bootcamp repo

  • there is now a bash script to automate all the following steps (to try out)
  • Greg's screencast explains all the steps for the manual approach, however the screencast refers to the old 'bc' repo, which has now been replaced with 'workshop-template'

Manual method:

  1. create an empty repo on GitHub (not a fork!), name it according to the bootcamp naming conventions: YYYY-MM-DD-site (check with swc admin for the site code)
    • usually, the lead instructor of a workshop sets up the repo and has ownership of it & manages pull request
    • init the empty repo with a readme file
  2. clone the empty workshop repo on local machine (GUI or with git clone repo-url - the clone URL can be easily copy pasted from the right hand side page on GitHub)
  3. create a branch called gh-pages (GUI or with git checkout -b gh-pages)
  4. get the clone URL for the official swcarpentry workshop template and use it to add a remote on local bootcamp repo: git remote add source <clone-URL> (source is just a name for the remote, can be something else)
  5. pull the gh-pages branch from the official template: git pull source gh-pages
    • if the empty repo was initiated with a readme file, this will create a conflict. That's normal. Edit the readme to remove all the text coming from the template, not relevant to bootcamp visitors.
    • once edited, do git add to resolve the conflict
  6. edit the content (mostly index.html) to match the new bootcamp
  7. push the gh-pages branch to GitHub (using the GUI or with git push origin gh-pages)
  8. the site is then live on (go check!)
  9. remove the official swcarpentry template as remote, to prevent accidentally pushing changes to it: git remote rm source (or whatever the name that was chosen for this source when adding it)
Edit - History - Print - Recent Changes - Search
Page last modified on October 14, 2015, at 10:28 EST