Project

General

Profile

History

Wiki » Software Overview »

Using Revision Control

This section explains how to share a project with other team members using Redmine, Git & RStudio.

This section outlines some common tasks for using revision control for a project. It assumes you:
  • Have already installed and configured Git & RStudio on your computer
  • You have a MCECS computer account
  • You have logged into the Redmine server (https://projects.cecs.pdx.edu/)

In general, these directions have been tested on a PC, Mac and should work on Linux. Be aware that there are some subtle differences - your experience may vary.

We'll refer to the command line - on a Mac that is a terminal and on Windows it is the command prompt.

Revision Control Basic Concepts

Revision control saves your code in two places, in hidden files on your computer, local repository, and on a server, remote repository or origin.

The system very efficiently (never worry about saving space by not saving often) keeps every version you save, so you always go back to any previous version when you break the code. The most recent version of the code is called the head.

There is an official version of the code, master; this is the code that everybody agrees works and is stable. Then there is your code your working on, a branch. Every team member will have their own branch where they have made changes to some files. You may share a team member's branch if you are working closely together on the same feature.

Think of the master as the trunk of a tree and each person's code they are working on as a branch off the main trunk.

When your new feature works and passes it's tests you combine it with the master code, merge, to update the master.

While your busy working on your branch, another team member may finish their changes and updates the master. Now the master code is ahead of your code, you have some older versions of files. You need to merge these changes back in to your branch. Most of the time this is not a problem, they have updated parts of the code you arr not working on. But if they changed some of the same sections you are working on - there maybe spots where your changes and their changes disagree, conflict. There are tools to help you edit your version of the code and resolve the conflicts.

Typical Workflow

The typical work flow is to get a copy of the project code, clone, make your own local working copy, branch, edit your code, regularly save a copy to the local repository as you make progress, commit, and occasionally save to the remote repository, push.

You regularly update from the master version where other people have made changes and combine the changes with your code, pull master & merge. It's important to do this every few days so it is easy to combine the small chunks.

After your code is complete, the tests pass and the project team is OK with adding it to the project, you update the master version, push master.

If you are starting a project, you create the project in Redmine, which creates a new empty repository, initializes repository. After the project is created you clone the repository on your computer. Using Redmine you can add users to the project and grant them access.

Step by Step Directions

The following directions use the TFDEA code as an example.