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.
- Getting a Copy of the Code
clone
Revision Control - Get Copy
- Creating a Local Working Version & Changing Branches
branch
Revision Control - Create Working Copy
- Locally Saving Changes
commit
Revision Control - Locally Save Changes
- Remotely Saving Changes
push
Revision Control - Remotely Save Changes
- Updating Local Working Version from Master
pull master & merge
Revision Control - Merging Master Changes
- Update Master from Local Working Copy
push master
Revision Control - Update Master
- Create a New Project on Redmine
initializes repository
Revision Control - Create Project