We ended up using submodules, I discovered that you have the option to add a branch name in the .gitmodules file through this SO post.
So I add the last line of this code snippet to all my master branches
path = SubmoduleTestRepo
url = https://github.com/jzaccone/SubmoduleTestRepo.git
branch = master
And when ...
I would have two requirements of shared code
My own builds are repeatable
I am not caught unaware by new bugs or breaking changes / I can actively choose when to advance to a newer version of the dependency
These are usually fulfilled by locking down the version of the dependency, and some sort of versioning scheme. Nuget is good here because I will always ...
To be honest, I've always struggled to find good workflows to use when dealing with submodules, specifically because of the reason you've pointed out:
But to make this work, we would need to change the submodules each time we merge Master to Stable.
I am not a fan of having to coordinate a ton of merges across a bunch of repos in order to implement day-...
I recommend to not version control DDL scripts, instead version control Logical Data Model (LDM) + Entity Relationship Diagrams (ERD's)
Build/buy a DDL generator that compares an 'as is' Physical Data Model (PDM) deployed on a DTAP instance, with the 'to be' PDM that is automatically derived from the version controlled 'to be' LDM (identified by a specific ...
Whoever said that has a particular notion of "good coder" in mind, which probably goes like this:
The Good Coder works alone on a Great Program that he or she designed alone.
There are no forks of the program, or release branches or anything of the sort, and so there is never any rebasing activity that creates conflicts.
When bugs are found in old releases ...