Postgres empty directories and GitHub - postgresql

Question

EDIT: Some context was missing from the original question.
My goal in using Git was to share the table structure and stored procedures of a mostly empty database under development with a second person building a REST API server
Git does not track empty directories, but PostgreSQL requires them at startup. How can I get the two working together?
Every search I make on the topic brings me to some variation of a Git workaround that involves adding dummy files to directories that would otherwise be empty. However, PostgreSQL did not appreciate that solution in at least the pg_tblspc directory.
The directories required by PostgreSQL at startup are:
pg_notify
pg_tblspc
pg_replslot
pg_twophase
pg_stat
pg_snapshots
pg_commit_ts
pg_logical/mappings
pg_logical/snapshots
I am running PostgreSQL from a Docker container as follows:
docker-compose.yml
version: "3.9"
services:
db:
build: ./pg_db/
image: db_MyDB
ports:
- "5432:5432"
volumes:
- ./pg_db/db_data:/var/lib/postgresql/data
./pg_db/Dockerfile
FROM postgres:14
ENV POSTGRES_PASSWORD=admin
ENV POSTGRES_USER=<admin password>
ENV POSTGRES_DB=db_MyDB
Then in the CLI...
git add .
git commit -m "something"
git push -u origin HEAD
Later, if I or another user then try to replicate the database on GitHub from the CLI...
git clone https://github.com/<user>/<project>.git
cd <project>
docker-compose -up
The result is a set of startup failures related to the missing, empty, directories listed above. Once I manually create them, PostgreSQL starts up, without any issues to my knowledge.

Answer 1

Generally speaking it is best to keep the schema object definitions in text files external to the database in some sort of change management framework. This can either be a home grown solution or one of the many existing solutions as shown in your link Change Management. In either case keeping this under version control e.g. Git is an extra layer of flexibility and redundancy.
The basic principle is to have schema(database object) definitions that live outside the database itself. Then have a procedure to apply those definitions or changes to existing definitions in an orderly fashion. Preferably in a way that allows you to both move forward to a new state as well as revert to previous state in the database itself. A version control tool over this works to maintain a history of changes to the schema as well as the other text, code, etc that goes along with any project. It also allows for branching to try out new ideas without interfering with an existing setup.

Answer 2

Thank you to Richard and Adrian for responding so promptly.
EDIT: Adrian highlights in a comment below that Git is a strong compliment to a Schema Management Tool
Git is the wrong tool. What I need is a Schema Management Tool several of which are highlighted in the PostgreSQL wiki here:
https://wiki.postgresql.org/wiki/Change_management_tools_and_techniques
Some context was missing from the original question.
My goal in using Git was to share the table structure and stored procedures of a mostly empty database under development with a second person building a REST API server. My approach of sharing the entire data directory caused some confusion and in hindsight I can see how pushing likely stale data around with schema changes would would be a terrible idea in most scenario's.
I have what I need, but if anyone would like to provide a more inciteful answer for anyone else who might wind up here in a search I'd be happy to accept your answer as the correct one.