Reputation: 15054
I'm exploring options for managing my team's data. Currently they exist in two different locations and not under version control. I'm seeking the wisdom of experienced git users as I'm fairly new to git.
I'd like to set up each location as a git repository and point to the other location as a remote. Is this possible? Is it going to cause issues when trying to reconciles differences if the data gets changed in one place and not the other? I'd like to simply create two git repositories and set each other as remotes, but I suspect (I hope I'm wrong) that they won't be able to know that the data is the same.
Upvotes: 3
Views: 450
Reputation: 47493
You can certainly do that. After all, that's what a distrubted VCS is all about. However, there are some issues you must pay attention to. For example it's not a good idea to push to a non-bare repository. Instead, you could have each team sending a request (e.g. via email) for the other team to pull from their repository.
However, what is usually done is to have one or many central bare repositories to manage synchronization easier. For example, a central development repository would allow everyone to push and pull from it, without thinking about pulling individual commits from different repositories. Another repository (or a branch of the first repository) could contain release branches for example.
This strategy kind of counters the idea of distributed VCS, but on the other hand eases use of such complicated tools, without hindering their awesome power.
In short, what you are asking for is very much possible. Whether it fits your development model is something you would have to decide (and perhaps do some trial and error).
Upvotes: 3
Reputation: 889
I wouldn't set up the repos in that manner, at the end of the day one repo should remain your master. I would merge the repos together and get rid of the other one if possible, or use that other one as a fork that you'll merge back in at a later time.
Upvotes: 1