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. Cordova, DBeaver, Dropbox, LabVIEW, Drupal7, Amplify, Laravel, Qooxdoo, Lazarus, Android, Drupal8, Eclipse, Azurite. If the only tool you have to deploy to packaging/patch orgs is Eclipse, you're restricting what can be automated after your process. 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. You can then use whatever Git tool you want to use to commit those changes to a branch of your repository. That will pull all the metadata from the package in the target org into your local directory. Using the macro, you can simply do something like: ant -propertyfile PATH/TO/CREDENTIALS/FILE retrievePackagedToSrc Here's an example of the target we use to retrieve packaged metadata:

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.

The packaging and patch orgs are only changed by an automated process which moves code from the repository to the 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 best practice we've settled around is that developers don't connect Eclipse to a packaging or patch org.

How to use eclipse with github