by Geoff Escandon firstname.lastname@example.org
Development in the Cloud is rapidly becoming an bazaar of languages and toolkits to build and deploy applications. Many of these tools are at home with version control, and developers would like to keep a consistent process for all their work. Following up from Setting up source control with Eclipse, let’s take a look at the common development lifecycle for Force.com and Git, using Eclipse and SourceTree.
Developing on your own, or in a team, it is good to establish a consistent process for getting the latest code and committing your changes. Many sites (github, bitbucket, code school) have detailed tutorials about the commands we are using in this process.
Figure 1. The basic dev process with Git.
Using SourceTree, the toolbar provides buttons for all our needed actions. The following section will detail the basic development process with an image of each SourceTree button that is used.
Figure 2. The SourceTree toolbar.
1. Pull: Before you start new development, be sure to pull the latest changes from the master repository. Other folks on your team are not sitting idle waiting for you! You want to have the latest code before you make your changes.
2. Development: Use Eclipse as usual to bring to life your VisualForce pages and controllers. This is where your skill and creativity comes in!
Figure 3. Create new VisualForce page in Eclipse.
3. Add: If you have setup your environment as described in our previous blog, SourceTree will detect changes saved in Eclipse, and display new and changed files as “Files in the Working Tree”. By selecting all files listed and clicking “Add”, all new changes will be staged. Clicking “Add/Remove” will also stage new changes, as well as remove deleted files.
4. Commit: Committing your changes makes them are part of your local repository. Git also records your name and email address with every commit you make. Always leave a meaningful message with each commit!
5. Pull: When working in a team, always pull down changes that have occurred since you last pulled. The green ‘Pull’ arrow may not indicate recent remote changes. Use ‘Pull’ to merge any changes before you push your changes.
6. Push: Ending this happy path is pushing your latest changes back to the master repository. Do not allow your customer and team miss out on the experience of your glorious code!
“Commit early, and Commit often”
This cannot be said with enough emphasis, “Commit early, and Commit Often.” (Google it.) Every day that you do any code, you should be committing and pushing changes. This does not mean push broken code. It simply means, “If my work is not complete, it is complete enough for another to pick up where I left off.” Do not be shy. Just do it.
Occasionally, when you pull just before you push (Step 5 of the Happy Path), you may encounter a conflict. Another developer on your team has made changes to a file that you have also changed. Git (rightfully) is first come first serve, and you are responsible for resolving the conflict. SourceTree will let you know that a conflict exists.
Figure 4. SourceTree conflict message.
SourceTree will also display the conflicting code in standard fashion. You may resolve the conflict using the ‘Resolve Conflicts’ options of SourceTree Action menu, or manually using Eclipse.
Figure 5. A VisualForce page with typical conflict indicators.
After resolving the conflict, you must commit the changes before continuing to push (Step 6 of the Happy Path).
Branch or Fork
Branching and Forking are functionality that really deserve their own post. Here is a quick overview.
Branching may be useful when you are required to work on two different tasks at once. It may also be useful to maintain “test” code separate from “production” code. While branching is very powerful, it can also be abused and quickly become a source of crippling overhead. Branches require meticulous attention. Branched code that does not get quickly merged back into the master branch can become “moldy” (ie. a source of errors). Following the practice of “Commit early, and Commit often” m
ay reduce the need for branches in your projects.
Forking is very useful for Open Source projects where an individual is encouraged to make their own modifications to the source code. There are several Force.com projects on github that you could fork today and customize as you need. If you have developed a great Force.com tool, perhaps you would make it available for forking!
You may have noticed that there was very little here specific to Force.com. Using git with Apex and VisualForce is really no different than any other language. To that end, there are many useful resources online that describe good use of git.
Some may also remark that particular features of the Force.com platform may prevent you from using git for 100% of your Force.com developement. This is ok. We acknowledge this and use git where we can. Not only does this process improve the delivery of your Force.com code, it also prepares you for any opportunity to work with the best development teams.