Skip to content

Latest commit

 

History

History
123 lines (94 loc) · 6.22 KB

working-with-github.md

File metadata and controls

123 lines (94 loc) · 6.22 KB
Raw

As articulated in the development docs, you first need to fork the repo and clone it to your computer.

Step 1. Fork the repo

To contribute to the web based documentation, you should obtain a GitHub account and fork the Langlotz Lab Site repository. Once forked, you will want to clone the fork of the repo to your computer. Let's say my Github username is vsoch, and I am using ssh:

git clone git@github.com:vsoch/radinformatics.github.io.git
cd radinformatics.github.io

Step 2. Set up your config

The github config file, located at .git/config, is the best way to keep track of many different forks of a repository. I usually open it up right after cloning my fork to add the repository that I forked as a remote, so I can easily get updated from it. Let's say my .git/config first looks like this, after I clone my own branch:

  [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
  [remote "origin"]
          url = git@github.com:vsoch/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [branch "master"]
          remote = origin
          merge = refs/heads/master

I would want to add the upstream repository, which is where I forked from.

  [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
  [remote "origin"]
          url = git@github.com:vsoch/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [remote "upstream"]
          url = https://github.com/singularityware/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [branch "master"]
          remote = origin
          merge = refs/heads/master

I can also add some of my colleagues, if I want to pull from their branches:

  [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
  [remote "origin"]
          url = git@github.com:vsoch/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [remote "upstream"]
          url = https://github.com/singularityware/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [remote "greg"]
          url = https://github.com/gmkurtzer/singularity
          fetch = +refs/heads/*:refs/remotes/origin/*
  [branch "master"]
          remote = origin
          merge = refs/heads/master

This would mean that I can update my master branch as follows:

git checkout master
git pull upstream master
git push origin master

Step 3. Checkout a new branch

Branches are a way of isolating your features. For example, if I am working on several features, I would want to keep them separate, and "submit them" (in what is called a pull request) to be added to the main repository codebase. Each repository, including your fork, has a main branch, which is usually called "master". THe master branch of a fork should always be in sync with the repository it is forked from (which I usually refer to as "upstream") and then branches of the fork consistently updated with that master. Given that we've just cloned the repo, we know that we are in sync with master, and can immediately checkout a new branch

# Checkout a new branch called add/my-awesome-feature
git checkout -b add/my-awesome-feature

The addition of the -b argument tells git that we want to make a new branch. If I want to just change branches (for example back to master) I can do the same command without -b:

# Change back to master
git checkout master

Note that you should commit changes to the branch you are working on before changing branches, otherwise they would be lost. Github will give you a warning and prevent you from changing branches if this is the case, so don't worry too much about it.

Step 4. Make your changes

On your new branch, go nuts! Make changes, test them, and when you are happy with a bit of progress, commit the changes to the branch:

git commit -a

This will open up a little window in your default text editor that you can write a message in the first line. This commit message is important - it should describe exactly the changes that you have made. Bad commit messages are like:

  • changed code
  • updated files

Good commit messages are like:

  • changed function "get_config" in functions.py to output csv to fix #2
  • updated docs about shell to close #10

The tags "close #10" and "fix #2" are referencing issues that are posted on the main repo you are going to do a pull request to. Given that your fix is merged into the master branch, these messages will automatically close the issues, and further, it will link your commits directly to the issues they intended to fix. This is very important down the line if someone wants to understand your contribution, or (hopefully not) revert the code back to a previous version.

Step 5. Push your branch to your fork

When you are done with your commits, you should push your branch to your fork (and you can also continuously push commits here as you work):

git push origin add/my-awesome-feature

Note that you should always check the status of your branches to see what has been pushed (or not):

git status

Step 6. Submit a Pull Request

Once you have pushed your branch, then you can go to either fork and (in the GUI) submit a Pull Request. This will open up a nice conversation interface / forum for the rest of the lab to discuss your contribution, and maybe test. At this time, any continuous integration (TBD) that is linked with the code base will also be run. If there is an issue, you can continue to push commits to your branch and it will update the Pull Request.