How Shoud I Manage Packages in Git?

There are 2 options when looking at Git for managing your X++ code. The main driver for which option you select is if you will only ever have 1 package in your code base or more than 1. This include any ISVs or any other item that will have a code footprint anywhere in F&O. To learn more about packages, please see https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/models. 

1 Package as a Branch

This option is the simplest. You would have 1 package as a branch. A good example of this is this GitHub project. It's a small package that add a features, it only depends on OOTB F&O packages and models and has no other dependencies not does anything else depend on it. It doesn't get any more simple than this. However, this may not work well for a project. If you're developing a product or any IP for F&O, this works well. You have a product "X". X does certain things. It can be installed as a stand alone thing. When you consider that a project solution footprint could have several packages from a few different ISVs, the 1 package as a branch option becomes unviable. I use this approach when developing community mods on GitHub. I used to have everything hosted in Azure DevOps but I wanted to be able to share it easily so I moved it to a public repo in GitHub. An example directory structure would look like this:

+---.git
+---.vs
+---PackageName
+---bin
+---Descriptor
\---Projects

To Find out more, please see this article.

Collection of Packages as a Branch

This option is more complex but gives you a lot more flexibility. Now we have a collection, 2 or more, packages that we want to have under version control. in TFVC, this is fairly easy but because of how Git works, this can get a little tricky. Git assume the branch directory doesn't exist prior to the creation of the directory (plus a .gitIgnore) happens on branch create rather than the directory existing before the branch is created. This means Git wants C:\AOSService\PackagesLocalDirectory or K:\AOSService\PackagesLocalDirectory to not exist prior to pulling the branch directory locally. You can see the issue that creates. It's possible to get around this with some command line commands. Whether using GitHub or Azure DevOps, you'll have to use the command line options to reconfigure the local repository. An example directory structure would look like this:

+---PackageName1
|   +---.vs
|   +---PackageName1
|   +---Descriptor
|   \---Projects
+---PackageName2
|   +---.vs
|   +---PackageName2
|   +---Descriptor
|   \---Projects

To find out more, please see this article.

Other Changes

Irrespective of the package management strategy you use, you will have to relocate where your projects to be inside the package when you create them. Git allows commits that a file based to 1 directory that represents a branch so we must have our project files in our package directory for that package.

What About Building Packages with Dependencies from Different Branches?

You can also mix and max at build between different branches if need be. Each branch could be mapped and built in a specific order if needed. This may only be an ISV or IP related problem.