1

Suppose we are 10 programmers on the project, working with git. Suppose we don't want to use remote internet (github) repository, and also not a remote network centralized git repository.

  • How can we now all synchronise?
  • Everyone has to declare other programmers' repository as a remote repository one after another?
Eimantas
  • 48,927
  • 17
  • 132
  • 168
user5157427
  • 241
  • 2
  • 7
  • 17
  • Can you not have a *local* server? – Biffen Oct 31 '16 at 11:22
  • yes sure I can . I ask this to understand the theoretical workflow of git with no centralized repository – user5157427 Oct 31 '16 at 11:27
  • You can setup mirrors? I'm not sure I get the point why you don't want a central repo? – hjpotter92 Oct 31 '16 at 11:49
  • I am just triyng to understand if central repo is a must in git workfow – user5157427 Oct 31 '16 at 12:29
  • 1
    There is no centralized repository in Git. It's just a useful convention to name one repository the "central" one, so that all developers can look to one place for changes. Otherwise, every developer would have to pull/push from every other dev. Possible, but requires a *lot* of discipline. You can just create a repository on a file share and use that as your central repo – Panagiotis Kanavos Oct 31 '16 at 12:58
  • Well, you can always email patches generated with ``git format-patch``… – Jonas Schäfer Oct 31 '16 at 14:10

2 Answers2

1

If you do not want to use a dedicated server there is always the possibility of using one of the developers' local repository as the "origin" that every other developer clones.

This can easily be done with SSH:

  1. Set up an SSH server on the origin machine.
  2. Give every developer SSH access to the machine (either using individual accounts, or a shared account, e.g. "developer").
  3. Have each developer clone the repository from that machine.

Cloning via SSH can be done like this:

git clone my-account@origin-machine:/full/path/to/repo/.git

...where my-account is the user account, and origin-machine is the machine that holds the origin repository.

Now, each developer can fetch and push changes, thus synchronizing with each other via the origin machine.

In a similar manner you can synchronize with several different machines if you so wish, by setting up more SSH remotes, e.g:

git remote add machine2 my-account@machine2:/some/other/path/to/repo/.git
git fetch machine2
...
git push machine2 my-new-branch

...etc.

However, there is a catch: By default you may not push changes to the branch that is currently checked out on the remote machine (git will warn you if you try to do so, and quite frankly you do not want to do it anyway). Hence, you will have to come up with a branching strategy that avoids such situations (e.g. having all developers work on separate feature branches rather than a common branch is a good start).

With that said, I would strongly recommend using a local dedicated server with a bare repository (it is typically always online, and you do not have the problems with checked out branches on the developer machine). The server does not have to be fancy - something as simple as a Raspberry Pi should suffice in a small team (there is a simple tutorial here).

Community
  • 1
  • 1
m-bitsnbites
  • 994
  • 7
  • 19
0

I think you will get the point reading the official reference. For the sake of your time you should consider promoting one developer to an integration manager which holds himself the main repository.

Or, simple as is, setup an internal git server (bare repository, although I recommend using gitolite) which is what we do at work, backups and such stuff come for free there.

maxik
  • 1,053
  • 13
  • 34