Disclaimer: I work for Gearset
I'm a little late to the party but hopefully I can add something of value - we've got a few largely product-agnostic whitepapers for download that might be useful to you, specifically:
- Simplifying Salesforce release management: talks about developing a process from a sandbox to sandbox model to something more complex targeted at the maturity and size of your team.
- Version control for Salesforce: this is the follow-up to it, and talks about adopting version control incrementally, again moving from sandbox to sandbox, through introducing version control, picking a branching strategy that suits your workflow, etc.
- Adopting Salesforce DX: this one's a little more of a thought piece about where DX fits into this process going forwards, and how you can get the most from DX with teams of mixed technical backgrounds.
They get a little product specific at times, but they're largely agnostic - you can follow a similar approach regardless of the tools you choose. You can download all of the above without needing to give us any contact info etc. at:
You can also use Gearset to directly compare and deploy to and from git repos in either the DX or Ant-style metadata formats. This is a really easy way to get that initial batch of metadata into your repo. There's a free 30 day trial etc., so you can do it in a few clicks - just pick a source org and a target bitbucket repo and branch, run a comparison, select all components, add a commit message and hit deploy, and your repo will be ready to go.
I agree with Bill that a subset of metadata makes sense as a starting point, but you're unlikely to get absolute consensus on what that subset should be. Gearset's default set of metadata sits at around 64 types at the moment, and we think that's a good starting point for a manual workflow. For a more automated flow that uses CI, we'd start by stripping that down further, getting your process working, then incrementally adding types as you move forward.
In terms of workflow, I'd echo some of the other posters - aim for a 1:1 mapping between feature branch and dev sandbox (or spin up scratch orgs as appropriate if you go the DX route). We then commonly see a staging / integration org that tracks your master branch, before a UAT environment then obviously prod. Master should always contain only code that you're happy to ship, and if it's broken / undeployable at any point then the priority should be to get that back into a shippable state asap. All merges to master should be via pull / merge request, and all deployments to staging / integration should be from master. From there, ideally you shouldn't have any changes being made directly to other environments - they should all flow from master.
If you do need to make changes directly into an environment like integration, I'd probably recommend setting up another environment for those changes, and then set up a job that monitors that environment and lets you pull changes back to a corresponding branch on a regular cadence. You can then follow the gitflow / PR model and merge that branch back into master on review. Gearset has a monitoring feature that'll notify you when an org has changed from its previous state, and push those changes to a branch in git with a couple of clicks, which would come in very handy here, but you can also set something like that up with Jenkins / TeamCity and the Salesforce CLI / Ant, for example - just a little legwork.
This is a fairly interesting topic to me, so if you want to talk about it feel free to open the on-site chat at gearset.com and leave a message - it'll come straight to the dev team and we're always happy to chat Salesforce DevOps :)
Hope that helps!