Wondering how to properly organize git repo for salesforce org (branching strategy)

Question

We have a little CRM project and I'm wondering how I could organize the whole git-sandboxes-deployment thing in a nice and smooth way.

At the moment, I don't think there's actually a big need to do this, as the project itself is quite small: mostly admin configurations (custom fields/objects, record types, page layouts, profiles etc.) and a couple triggers. But I wanna seize the opportunity to practice and learn how to organize things properly. I'm the only developer on the project, there's no tech lead either, so I basically have free rein over the "technical management" side of things.

So, we have our production org and 2 sandboxes; one is for development (dev sandbox) and another one is for pre-release tests (partial copy). I do my development on the dev sandbox, then deploy to the partial copy sandbox where we test our work together with the client and then deploy to production.

Now, I'd like to keep a git repo for this. Again, I don't really see a major need for this, but I wanna "use" this project in order to practice. So I wonder:

1. When you initially create a git repo for your org, what do you put on it? I create a project with manifest and authorize my org, but what data should I pull from my org and update to my master branch at the very beginning?

2. What's the sandbox/repo "relationship"? I though of creating a different branch for each new feature that has to be implemented, than have another branch for pre-release, and then merge them to master branch (prod). But I'm very new to this and I might be writing something very stupid.

3. How do you track configuration changes in your repo, such as new record types/fields/page layouts etc.?

Pardon my newbie questions but I'm quite new to this!

Answer 1

When you initially create a git repo for your org, what do you put on it? I create a project with manifest and authorize my org, but what data should I pull from my org and update to my master branch at the very beginning?

Ideally, everything. Fields, Objects, Layouts, Profiles, everything you need to completely recreate the org (hint: so you can move on to Scratch Org development).

What's the sandbox/repo "relationship"? I though of creating a different branch for each new feature that has to be implemented, than have another branch for pre-release, and then merge them to master branch (prod). But I'm very new to this and I might be writing something very stupid.

This is a fairly common strategy. We have basically three branches, master (production), uat (for training and QA), and dev (for development). Our process starts by branching from dev, developing a feature in our own Developer Sandbox/Scratch Org, then merging back to dev, then uat, then master.

How do you track configuration changes in your repo, such as new record types/fields/page layouts etc.?

Use the push/pull commands instead of deploy/retrieve. You can Enable Source Tracking in Sandboxes. Afterwards, force:source:pull will retrieve all changes, including changes to page layouts, profiles, and so on. It's a far better solution than just developing without this feature.