We are new to git, but this fundamental question needs to be sorted out before we can begin. It’s two devs who have been working standalone for a while. Now the time has come to adopt git (at the first sight of sending each other zips and poking the same files). I work on both front&back, he works only on the back. So teamwork only happens on the backend. It’s a WordPress plugin that currently has a standalone backend and a frontend and they are installed separately. (Commercial, so no SVN here.) Obviously they will be merged into one, especially for production/release. What’s the best practice here? My ideas:
- A. 1 repo that clones into the
/wp-content/plugins/folder of our dev WP installations,
.gitignoreany other folders from plugins. One day when we are ready to forge the two, we’ll just create a common
ourpluginfolder and move the files there.
- B. 2 repos, one for each side. Eventually one side will get abandoned when its files begin existing on the other one. We’d rename the winning repo, while losing versions/history of the transferred files.
- C. 2 repos, but combining the actual repos once we no longer work standalone. Since I’m new to this, it might be a clusterfck but I read that it’s possible. Or we could decide what we want now and avoid this as it’d turn into A. anyway.
- D. 2 repos. Combine only at production build and do not store the built/combined version on git at all. Not sure what tool would pull from 2 repos, build, and combine things into one. Sounds fancy. Would need to keep the front up to date for the backend guy on his machine though (scheduled
git pullor something).