Do you use Git with Salesforce? What are the key challenges that you have encountered in using Git for Salesforce? We are about to make a decision on Git, and would like to learn from this community.
The two answers @Jagular referenced are good and @JonathanHersh is right about git just being a tool. Most of what I'm saying below isn't git specific, though. The same could be said about SVN, CVS, etc.
Here are some pain points, assuming a setup where each dev has their own org (e.g. developer edition). They can be dealt with, but are good to be aware of if you are using git + SFDC for the first time.
Need to have a decent understanding of the metadata XML files
In the end you are storing and merging a bunch of metadata XML files in git, so you need to understand them and which ones change when and how. Some of this can be mitigated a little by using something like MavensMate or the Force.com IDE which can manually build your package XML and take care of subscriptions.
@Greenstork points out in his answers and others do as well that your developer work flow should not include refreshing from the server. This is generally correct, but if you are doing a decent amount of work on things through the normal SFDC UI, and you have a bunch of profiles in git, you either need to know all of the different pieces of the .profile XML to edit across all of your profiles, or you refresh. If you have devs on different instances, and in some cases the same instance (there can be dependencies on when org was created), they could have different features available. For example, an older org has Manage Self-Service permissions, a new one does not. Additionally, a .profile XML file is updated to only have contents that have to do with whatever was included in the refresh, so you better make sure that your package.xml (i.e., subscriptions) are accurate.
Some things can't be versioned
There are some things that can't be retrieved via the metadata API and therefore can not be part of your version control. You need to maintain those changes separately somehow (list in git, google doc, wiki, etc.). This isn't a git problem, per se.
Changes made in production
Admins can make changes in production the second after you deploy. How will you handle getting those changes back into git? Will you? If you don't do any dev work for a while do you start by trying to get all of those production changes in to git? It's easy to say that admins have to follow your process and use git, it's another thing for that to happen.
If you delete something in your branch and check it in, it removes it from git and the next dev has it removed from their branch; however, it is not actually removed from their org. A separate destructive change is needed.
When you switch branches and you are using the same org, your org doesn't change to be exactly what is in your branch even after you apply the changes in the branch. If you have other changes in your org they won't be deleted. Carefully consider when you need a new org vs. using an existing org.
All of that being said, I use git with git-flow with a team where every dev has their own org, continuous integration, and automated builds and it works really well. I couldn't imagine going back to a shared org for everyone on the team.
The accepted answer for this question discusses using Git with multiple developers:
The accepted answer for this question talks about managing Git with Sublime
I am using GIT with Salesforce which automatically take daily backup of metadata of nearly 6-7 environments. You can check here :