Patch orgs in Salesforce.com are somewhat comparable to release branches in a Versioning Control system as both represent different timelines of the same codebase.

I just switched from Subversion to Git(hub) and successfully connected my packaging org to my remote Git repository on Github.

I now want to incorporate my existing patch orgs into the same repository as braches, so I cannot not only compare inside the Force.com IDE but also on Github.

What I am struggling with is the fact that there is a mismatch between multiple disconnected Eclipse projects for Trunk and Patch orgs on my machine and a single repository on Github.

I couldn't find a single tutorial about that on the web, so I hope somebody is willing to share some tricks and tips here.

enter image description here

1 Answer 1


The best practice we've settled around is that developers don't connect Eclipse to a packaging or patch org. Instead, all coding is done in the developer's own DE org, committed to a branch in GitHub, and then deployed to the patch/packaging org by Jenkins (or any other automation tool of your choice).

The packaging and patch orgs are only changed by an automated process which moves code from the repository to the org.

If you have work done in a patch org you need to pull into git, you might be best to just use Ant to retrieve it rather than using Force IDE. Here's an example of the target we use to retrieve packaged metadata: https://github.com/SalesforceFoundation/Cumulus/blob/feature/721-allocations/build.xml#L402

That target calls this macro: https://github.com/SalesforceFoundation/Cumulus/blob/feature/721-allocations/lib/ant-salesforce.xml#L192

Using the macro, you can simply do something like:

ant -propertyfile PATH/TO/CREDENTIALS/FILE retrievePackagedToSrc

That will pull all the metadata from the package in the target org into your local directory. You can then use whatever Git tool you want to use to commit those changes to a branch of your repository.

I can't stress enough how important it is to invest in build scripts which can deploy your managed package code from the repository into a packaging org so you can automate that process. If the only tool you have to deploy to packaging/patch orgs is Eclipse, you're restricting what can be automated after your process. The purpose of automation is not only to make your life easier but also to ensure that nothing goes into your packaging/patch orgs before it's been tested elsewhere.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .