How to use GIT on multi dev environment

Question

I have previous experience using GIT in other development environment and I never had much troubles using it.

We where using SVN for salesforce, however we want to migrate to GIT for the uncountable number of advantages compared to SVN.

I could configure the remote and local repo without any problem and also I could commit and push the changes to my remote repo.

However, I can't figure out how can we use GIT when more than one developer is doing changes on the repo. I always get conflict after refresh from server.

Sample where bought dev's are working on the same repo/branch

Dev 1:

1. Refresh from Server
2. Change code
3. Save to Salesforce
4. Commit
5. Push to remote

After Dev 1 pushing

Dev 2 (Steps A):

1. Refresh from Server
2. Change code
3. Save to Salesforce
4. Commit
5. Push to remote (Error: out of date)
   1. If dev 2 try pull (or fetch + merge) then Conflict

Other steps we tried Dev 2 (Steps B):

1. Refresh from Server
2. Pull (or fetch + merge) then Conflict

I was thinking in the possibility to use two branches: one for dev, just to be able to push commits to remote repo and the merged code will come always from Salesforce. But this practice will kill some of the GIT benefices as diff and blame.

I've tried searching on Google unsuccessfully.

Answer 1

There are a couple issues with how you're using git, let me talk about each.

The problem

First, you're treating your Salesforce server as the truth, instead of git. By doing a Refresh from Server each time before you're starting to code, you are updating your working directory with whatever has changed in Salesforce. This will be reflected as a change pending commit on your local branch.

Second, you're having developers share a Salesforce instance. Imagine that you're each working on separate features on separate branches in git but on the same instance. If you do something like refreshing from server, all the stuff from your colleague's branch is going to show up in your index, ready to be committed. Worse, what if you're editing the same metadata files, you're constantly overwriting each other.

The solution

Each developer needs his/her own Salesforce instance. Yes, keeping those instances up-to-date with a stable build (master branch) poses its own challenges but there are a ton of articles out there on continuous integration with Salesforce. This allows for feature development and accurate testing (since Salesforce controls the unit test environment) within your own branch and instance.

Also, you should be treating git as the truth. Right now, you're trusting your instance but why wouldn't you look to your stable build in git first. Step 1 in a VCS system should be a Pull, not a refresh from server. In this scenario, who cares what is on the Salesforce server, if it's not in git it does not exist. And would you want it any other way, git is really designed to hold the history of your changes and Salesforce is not.

Answer 2

The workflow that I'd recommend (for updating code from a git repository and sending it to your Salesforce dev org) is:

• turn off online development in Eclipse;
• git fetch;
• get merge;
• deploy metadata to your Salesforce dev org using Force.com Migration Tool;
• refresh from server in Eclipse;
• turn on online development in Eclipse.

You'd also need to work out what you want to commit prior to the fetch & merge or whether you just want to stash your work.

Answer 3

Here is a simple but workable workflow for a moderate sized team

Our development workflow, while not close to a CI setup keeps all our code safely backed up, allows everyone to have the latest code and is pretty simple to implement. Which is key as we have a team filled with devs of all abilities, some of who are not familiar with git.

We have the standard git setup with a master and a develop branch. All the actions I'm going to describe below relate to the develop branch.

Every developer uses their own sandbox and pushes back to develop.

There are a lot of challenges with git and salesforce (pre Salesforce DX).

SETUP

The basic steps we use to set up a repo for the first time are:

1. Set up your sandbox and download as much metadata as you intend to track.
2. Delete the contents of src
3. Pull down the contents of the remote repo. See code block 1
4. Pull down the contents of your org (again). Git will track the changes.
5. Push back up.

Code block 1:

//get the repo ready, run 1 time to set everything up
git init
git remote add origin [email protected]:yourorg/yourproj.git
git pull origin develop
git checkout develop

DAILY WORK

1. Pull from develop (and compile any changes up to your sandbox)
2. Create a new feature branch
3. Do work
4. Commit your branch
5. Pull again and merge your branch - push.

Code for this:

//start the day by pulling in others changes
git status
git pull

//used everyday, rinse & repeat after dev feature is done
git checkout -b feature/TASK-####
git status
git add ...// match to your changed files
git commit -m "fixed some stuff"
git checkout develop
git fetch
git pull
git merge feature/TASK-### //hope you don't get a merge conflict
git push

This takes care of about 90% of the stuff we need.

Of course there are merge conflicts and other issues that we periodically encounter which I'm not going to go into here... but you can avoid most of these if you pull regularly, pull often.