Version Control¶

The Dataverse Project uses git for version control and GitHub for hosting. On this page we’ll explain where to find the code, our branching strategey, advice on how to make a pull request, and other git tips.

Contents:

Where to Find the Dataverse Code
Branching Strategy
- Goals
- Branches
How to Make a Pull Request
How to Resolve Conflicts in Your Pull Request
Adding Commits to a Pull Request from a Fork

Where to Find the Dataverse Code ¶

The main Dataverse code at https://github.com/CeON/dataverse but as explained in the Introduction section under “Related Projects”, there are many other code bases you can hack on if you wish!

Branching Strategy ¶

Goals ¶

The goals of the Dataverse branching strategy are:

allow for concurrent development
only ship stable code

We follow a simplified “git flow” model described at http://nvie.com/posts/a-successful-git-branching-model/ involving a “master” branch, a “develop” branch, and feature branches such as “1234-bug-fix”.

Branches ¶

The “master” Branch ¶

The “master” branch represents released versions of Dataverse. As mentioned in the Making Releases section, at release time we update the master branch to include all the code for that release. Commits are never made directly to master. Rather, master is updated only when we merge code into it from the “develop” branch.

The “develop” Branch ¶

The “develop” branch represents code that was stable enough to merge from a “feature” branch and that will make it into the next release. Like master, commits are never made to the develop branch. The develop branch is where integration occurs. Your goal is have your code merged into the develop branch after it has been reviewed.

Feature Branches ¶

Feature branches are used for both developing features and fixing bugs. They are named after the GitHub issue they are meant to address, so create a GitHub issue if you need to.

“{USERNAME}_3728_doc_apipolicy_fix” is an example of a fine name for your feature branch. It tells us that you are addressing https://github.com/IQSS/dataverse/issues/3728 and the “slug” is short, descriptive.

How to Make a Pull Request ¶

Pull requests take all shapes and sizes, from a one-character typo fix to hundreds of files changing at once. Generally speaking, smaller pull requests are better so that they are easier to code review. That said, don’t hold back on writing enough code or documentation to address the issue to the best of your ability.

If you are writing code (rather than documentation), please see Testing for guidance on writing tests.

The example of creating a pull request presented in this section and its subsections has to do with fixing an important issue with the Documentation but applies to fixing code as well.

Find or Create a GitHub Issue ¶

For guidance on which issue to work on, please ask! Also, see https://github.com/CeON/dataverse/blob/develop/CONTRIBUTING.md

Let’s say you want to tackle https://github.com/IQSS/dataverse/issues/3728 which points out a typo in a page of Dataverse’s documentation.

Create a New Branch off the develop Branch ¶

Always create your feature branch from the latest code in develop, pulling the latest code if necessary. Your branch should have a name like “{USERNAME}_3728_doc_apipolicy_fix” that starts with the nickname, then issue number you are addressing, and ends with a short, descriptive name. Underscores (“_”) in your branch name are ok, but please try to avoid other special characters such as ampersands (”&”) than have special meaning in Unix shells.

Commit Your Change to Your New Branch ¶

Making a commit (or several commits) to that branch. Ideally the first line of your commit message includes the number of the issue you are addressing, such as Fixed BlockedApiPolicy #3728.

Push Your Branch to GitHub ¶

Push your feature branch to your fork of Dataverse. Your git command may look something like git push origin {USERNAME}_3728_doc_apipolicy_fix.

Make a Pull Request ¶

Make a pull request to get approval to merge your changes into the develop branch.

How to Resolve Conflicts in Your Pull Request ¶

Unfortunately, pull requests can quickly become “stale” and unmergable as other pull requests are merged into the develop branch ahead of you. This is completely normal, and often occurs because other developers made their pull requests before you did.

The Dataverse team may ping you to ask you to merge the latest from the develop branch into your branch and resolve merge conflicts.

Here are some steps to do so that make use of GitHub Desktop and Netbeans.

In GitHub Desktop:

Sync from develop.
Open the specific branch that’s having the merge conflict.
Click “Update from develop”.

In Netbeans:

Click Window -> Favorites and open your local Dataverse project folder in the Favorites panel.
In this file browser, you can follow the red cylinder icon to find files with merge conflicts.
Double click the red merge conflicted file.
Right click on the red tab for that file and select Git -> Resolve Conflicts.
Resolve on right or left (if you select “both” you can do finer edits after).
Save all changes

In GitHub Desktop:

Commit the merge (append issue number to end, e.g. #3728) and leave note about what was resolved.

In GitHub Issues:

Leave a comment for the Dataverse team that you have resolved the merge conflicts.

Adding Commits to a Pull Request from a Fork ¶

By default, when a pull request is made from a fork, “Allow edits from maintainers” is checked as explained at https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/

This is a nice feature of GitHub because it means that the core dev team for Dataverse can make small (or even large) changes to a pull request from a contributor to help the pull request along on its way to QA and being merged.

GitHub documents how to make changes to a fork at https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/ but as of this writing the steps involve making a new clone of the repo. This works but you might find it more convenient to add a “remote” to your existing clone. The following example uses the fork at https://github.com/OdumInstitute/dataverse and the branch 4709-postgresql_96 but the technique can be applied to any fork and branch:

git remote add OdumInstitute git@github.com:OdumInstitute/dataverse.git
git fetch OdumInstitute
git checkout 4709-postgresql_96
vim path/to/file.txt
git commit
git push OdumInstitute 4709-postgresql_96

Previous: Troubleshooting | Next: SQL Migration