I'm new to GIT environment, so kindly bear with me :) In our project we are planning to move to GIT from RTC , and the code is shared as a tarball via ftp. The tricky situation is , we are having our office at 2 different places . we will create a GIT server , say at location A and complete the code migration/import @ A and later setup an exact setup @ B and subsequently synchronizing A to B’s GIT environment. (mirroring A to B and making B as master) . Is this approach feasible ? if so, during the process what are precautions we should incorporate like permission issues etc.(I understand , it doesn’t server the DVCS purpose of GIT, but still , like to know )
Also, if the above approach if possible , can it be executed via GitLab ?
Thanks!
I'd comment but the explanation is too long, so here goes.
Git is basically a distributed system, where changes are
push
-ed andpull
-ed between repositories. Every 'checkout' or 'clone' is a copy of the entire repository, and there isn't really such a thing as the 'central repository'. At best there is an agreement as to which repository is central.First you set up an empty GitLab repository A. You then
clone
it into a working environment W:git clone git@gitlab.localnet:path/to/repo.git
(gitlab explains this), or, alteratively, create a new local repository, and add the remote:You then add the files from your tarball,
commit
(to W), andpush
it back to your gitlab instance A.If you want to sync to site B, you could use that same repository W, and register a second remote repository B (
git remote add B git@....
). You can then simplygit push B
.In short, you'll need a third working repository,
pull
-ing the changes from A andpush
-ing them to B.I'm not familiar with RTC, but I am with several others, such as Subversion, which allows you to specify read/write permissions on any part of a repository (even branches). Git however does not have a permission system. You'd configure that on a per-repository level using GitLab. This means, that if your RTC permission scheme includes different permissions on a per project basis, you will now have to create a separate repository for each project.
There are a lot of ins and outs to this so I can recommend spending some time with the documentation before making such a transition.