Skip to content

Using GitKraken with FHIR

Ewout Kramer edited this page Oct 2, 2018 · 2 revisions

GitKraken is a cross-platform tool that offers a graphical user interface to work with Git. This topic provides documentation for getting started committing to the FHIR spec with GitKraken.

First, download and install the latest version of GitKraken: https://www.gitkraken.com/

Create a Local Clone

Once you have the GitKraken client installed, you'll need to clone the FHIR repository locally. A clone is a local copy of the repository that you can use. Git is a distributed source control system, which means that each copy of the repository can manage its own set of changes.

NOTE: For SVN users that already have a local checkout, do not clone into that directory. Instead, create a new directory for the Git clone.

To clone the repository, first, copy the repository URL from the main page of the repository:

FHIR Clone or Download Dialog

Next, go to GitKraken, select "Clone Repo" from the "File" menu and paste the url into the "Url" textbox. The dialogbox allows you to change where the local copy will reside. Start cloning by clicking "Clone the repo".

FHIR GitKraken Clone Dialog

Note that this will create a sub-folder with the same name as the repository (fhir in this case) within the directory specified in the "Where to clone to" textbox, so you do not need (nor should you) create that directory yourself.

Making and Committing Changes on a Feature Branch

You will do your work on your own "feature branch", which is a branch of the main branch, normally called "master". Before you commence work on a bug or new feature, you will need to make sure our local copy has the latest changes coming in from other authors on that master branch. Obviously, if you have just cloned a repository, you will already have the latest changes.

"Getting Latest"

To update your local copy with master, right click on the "master" branche and select "Pull (fast-forward if possible)" (since this will "pull" the other author's changes from the github server into your own copy):

GitKraken Pull menu

This will display the pull dialog:

GitKraken will integrate the changes with your local copy, and show a dialog reporting success when done in the right upper corner of your screen:

GitKraken Pull success

If the pull fails, you will see this:

GitKraken Pull failure

Note that GitKraken mentions "merge conflicts" in this dialog. When this happens while you are doing a pull, this means that you have accidentally been making local changes directly on the master branch, and not on your own feature branch. If you follow the instructions in this document this should never happen.

Creating a feature branch

Once you have an up-to-date local copy, making changes to the spec involves:

  1. Creating a local "branch"
  2. Committing the changes to your local repository
  3. Pushing your changes to Github
  4. Creating a pull request

Creating a local branch

First, create a local branch with a descriptive name. Right click on the repository folder and select "Create branch...":

TortoiseGit Create Branch Menu

This will display the "Create branch dialog":

TortoiseGit Create Branch Dialog

Enter the name of the branch, brynrhodes-cdsresources-qa in this case, and check the "Switch to new branch". Then click okay and you TortoiseGit will create the branch and switch to it:

TortoiseGit Create Branch Complete

Note: Creating a branch in Git is a very lightweight operation, all it really does is remember where you were in the commit log when you created the branch.

Committing your changes

Once you have made your local changes and verified that they build locally, you need to commit your changes to your local repository. Right click on the repository folder and select Git Commit -> "branch name", where "branch name" is the name of your feature branch:

TortoiseGit Commit Menu

This will open the Commit dialog, showing a list of the files that you have changed in your working directory:

TortoiseGit Commit Dialog

By default, any files that are modified will be selected. Add a commit message, typically starting with GF#XXXX: where XXXX is the number of a GForge tracker item that covers the change you are making. In this case, we're just making some QA updates, so there isn't an associated GForge tracker.

NOTE: The "Not Versioned Files" section lists files in your directory that aren't part of the repository. For example, if you've added a new file, you have to tell Git about it in order to include it in the commit. Make sure you include any files you've added, otherwise they won't be in the commit and they won't make it to the remote repository, usually resulting in a build failure.

Once you're happy with the commit, press the Commit button to start the commit process:

TortoiseGit Commit Success

Pushing your commits to Github

Once you've successfully committed your changes to your feature branch in your local repository, they need to be pushed to the remote repository. From a successful commit, you can start this process by selecting the "Push" button displayed in the above dialog, but you can also always execute a Push from the TortoiseGit right click menu. The Push dialog lets you choose what you want to push:

TortoiseGit Push Dialog

This dialog allows you to "push" changes from a local branch to a remote branch in the remote repository. Initially, the Remote: branch is empty (because this is a new feature branch that currently only exists in your local repository). What we want to do is create the same branch in the remote repository, so copy the name of your Local branch and paste it into the Remote branch. Also, be sure to check the "Set upstream/track remote branch" option, this tells Git that you want these two branches to be "the same", so that the next time you commit changes to this branch locally, Git will by default know where they should be pushed.

Leave the rest of the options set to their defaults and select OK to start the push:

TortoiseGit Push Success

Creating a pull request

Once your feature branch is pushed to the remote repository, you'll need to submit a "Pull Request" (often shortened to just PR) in order to request that your changes be reviewed and merged into the master branch. Although you can do this with the TortoiseGit client, the GitHub user interface is a bit more user friendly, just navigate to the repository main page and look for the banner indicating the branch was just pushed:

FHIR Recent Push

Click the "Compare & pull request" button to create a pull request for your feature branch:

FHIR Open Pull Request

Click the "Create pull request" button and your pull request is submitted!

Switch back to master

Once you've submitted a pull request, the change will be reviewed and merged into the master branch. Before making any additional changes, you'll need to switch back to the master branch. To switch, right click on the repository folder and select "TortoiseGit|Switch/Checkout..."

TortoiseGit Switch Menu

This will bring up the "Switch" dialog to let you choose the branch you want to switch to:

TortoiseGit Switch Dialog

Select the master branch, leave the rest of the options as they are, and click OK:

TortoiseGit Switch Success

This "switches" you back to your local master branch.

NOTE: This means the changes you just made on your feature branch are no longer in your working directory, they are in a pull request that needs to be reviewed and merged into master. Once the change has been merged to the master branch, use "Pull" to get those changes into your local repository's master branch.