Git best practices for Bioconductor Team

Nitesh Turaga
Fri Mar 2 14:15:59 2018

1. Check the diff before pushing

Before git add

git diff

after git add

git diff --cached

after git commit

git diff --staged

between commit and HEAD

git diff <commit_hash>

2. Small Commits and frequent

  • Commit code whenever you have made a single logical change. Allows for writing concise but descriptive commit messages

  • Small and frequent commits allow functionality to isolate bugs,

git bisect

3.1 Use feature branches

When to use a feature branch

  • You will be committing “work in progress” changes to save progress that leave your application in a broken state and shouldn’t go to production

  • There will take multiple logical changes to the codebase that are part of a larger project

  • There will be several commits in a row that all depend on each other and should be in order

3.2 Don't use feature branches

When you don’t need a feature branch

(*i.e it’s okay to commit to master)

  • You’re making a small change that fits nicely inside one commit

  • Bug fixes/hot fixes for fixing typos, etc

  • Previous/future commits won’t affect this commit

3.3 Don't know when to use a feature branch

If the “small” changes on a master branch get out of hand,

consider,

git stash

git checkout -b new-feature

git stash apply {1}

4. Commit messages

Every commit message should describe why the code was changed – or what a change accomplished – at an appropriate level of detail

Here are some code smells or signs that you’ve writing a bad commit message:

  • The message is less than 3 words
  • Your message is too high-level (it’s hard to be too low level)
  • You don’t know what changes are being committed

If you have a bad commit message

git commit —amend

4.1 Formatting commits

The commit message has a “title” and “paragraph”

Eg:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together

Refer to this link on how to write good commit messages:

https://chris.beams.io/posts/git-commit/

Good way to check commit history, (see all the titles of commits)

git log --oneline

Commit code that works (builds/loads)

At a minimum, every commit should atleast

build

R CMD build <package>

install

R CMD INSTALL <package> 

Test before commit to `master`

Merge commits with master only if they work, otherwise keep them on the feature branch.

git mergetool

If you have trouble merging conflicts, a good way to merge branches is using

git mergetool

Advantages,

  • GUI opens up to see where the diff occured

  • Click and choose HEAD vs commit

Git Feature-branch workflow - 1

Quick look at remotes

origin  git@github.com:Bioconductor/mypackage (fetch)
origin  git@github.com:Bioconductor/mypackage (push)
upstream    git@git.bioconductor.org:packages/mypackage (fetch)
upstream    git@git.bioconductor.org:packages/mypackage (push)

Git Feature-branch workflow - 2

Start with master branch

(make sure master is synced with git@git.bioconductor.org)

git checkout master

git fetch --all

git merge upstream/master

git merge origin/master

Git Feature-branch workflow - 3

Once synced, checkout a new feature branch

git checkout -b new-feature

add and commit changes

git status
git add <some-file>
git commit

Git Feature-branch workflow - 4

push new feature branch to remote( github only)

-u create a new branch on github

git push -u origin new-feature

NOTE: once the new-feature branch is created, subsequent push(s) will be

git push origin new-feature

Git Feature-branch workflow - 5

merge with master (github)

git checkout master 
git pull (or) git fetch / merge
git merge new-feature

push github master to Bioconductor master

git checkout master
git push upstream master
git push origin master

Pull Requests

Eg:

https://github.com/Bioconductor/RGalaxy/pull/1

– Reviewer

– Leave comments if needed on the code and review

– Make sure the author of the PR did a version bump as well.

If not,

Command line options:

git checkout -b <user-master> master

## Change DESCRIPTION file for version bump

git add

git push

– Push to both Github and Bioconductor

– Leave comment at the end, saying what issue the PR deals with

(Pro tip: You can say “Closing #1” to reference a issue and close)

Squash and when to use

Squash commits in the feature branch if you have a large number of commits

Eg: This resets, the last 30 commits from HEAD

git reset --soft HEAD~30

Add a new commit message which is meaningful as a summery for the last 30 commits

git commit -m "New message for the combined commit"
git push 

References