Sign up ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Patch orgs in 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 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

share|improve this question

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:

That target calls this macro:

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.