Git push/pull between team members local repositories

Question

Lets say there is a team with 4 developers. We also have a central repository for our project. Developers push and pull from central repository. Here(in Decentralized but centralized section) it says that its possible to push/pull between team members local repositories.

Each developer pulls and pushes to origin. But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams...Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa

Now question is how to define remote name bob which is pointing to Bob's repository. If it matters developers possibly use different operation systems.

Answer 1

TL;DR - You want to perform the steps in chapter 4.4 for each machine serving as a remote.

Getting a true distributed workflow is not all that difficult if you have the freedom between your machine and the machines you want to share with. Essentially you need each machine serving a repo to act as an SSH git server.

A few answers here state that you can simply add users between the machines and use the user password to establish SSH. Chapter 4.1 and 4.4 of the git book also detail the creation of a single user that grants access to remote requests by a list of SSH keys in the ~/.ssh/authorized_keys file. This seems like a nice consolidated approach to managing the access given to your colleagues, but still requires managing user keys in the authorized_keys file for the consolidation account. Something to consider since this is "your" dev box and not a proper "server".

Having never used git daemon I can't exactly say how much better or not it is, but it does seem like a viable option if you're willing to use the git protocol, and have a good understanding of running it on each machine that should serve a repository from a secure position in your network. It might also be helpful here to state that the documentation mentions the following when referring to firewall settings:

If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on

Answer 2

If you establish a user account on the host and access permission on the repo, someone else can push/fetch over SSH with or without establishing a named "remote".

git push user@host:/path/to/repo branch

If you share code frequently, you can setup a named remote to remember the server path:

git remote add remotename user@host:/path/to/repo

If it's OK that sharing involve close coordination (and probably very loose security), you can fire up a short-lived git daemon on the "master" as needed: git equivalent of 'hg serve'? In this case, the above sharing commands still apply, but the user@host:/path will be replaced by git://host/. See also git daemon documentation.

Alternatively, you could setup a separate dedicated repository to use for intermediate sharing: How do I setup a staging repository in git?

Answer 3

I wanted to do a similar thing, in my case I was looking for an easy way to synchronise a project on an embedded system (running Linux). Previously I just setup a shared internet connection and pulled from the centralised repository. But I didn't find it easy to work like this, and sometimes my internet connection is just poor.

In the following article the use of git daemon is explained very nicely to solve this problem. I'll just put a brief copy of the contents here: http://railsware.com/blog/2013/09/19/taming-the-git-daemon-to-quickly-share-git-repository/

Setup the following aliases for read access (serve) or read/write access (hub) to your repositories:

$ git config --global alias.serve "!git daemon --base-path=. --export-all --reuseaddr --informative-errors --verbose"
$ git config --global alias.hub "!git daemon --base-path=. --export-all --enable=receive-pack --reuseaddr --informative-errors --verbose"

Then on the host just execute git serve or git hub from the directory where the repositories you want to share reside. Now on the client one can execute git clone git://x.x.x.x/path/to/repo to access the local repository on the host!

For windows users:

• Use double quotes in the commands to setup the aliases
• Be sure to 'hang' the command-prompt for it to not output any line by right clicking on the title bar and choosing Edit->Mark. Otherwise connections to clients might be interrupted due to a bug in git (according to a comment in the blog post).

Answer 4

If the two repos share a filesystem namespace you can just use the filesystem paths directly. Otherwise the developers can easily run local git servers, on e.g. a VPN where access is already workably private the git daemon command will serve fetches just fine, otherwise you can set up ssh access on a dedicated port to achieve the same effect with a bit more work.

Answer 5

Similar to GIT clone repo across local file system in windows

Per J.F.Sebastian reply:

$ git clone --no-hardlinks /path/to/repo

The above command uses POSIX path notation for the directory with your git repository. For Windows it is (directory C:/path/to/repo contains .git directory):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

The repository will be clone to C:\some\dir\my_project. If you omit file:/// part then --local option is implied.

Answer 6

It's a very common thing like Alice and Bob need to work on some functionality together. In the mean time, the development should be carried on different branches by different developers.

Simple approach would be:

• Create a new branch sprint_1, Alice and bob checkout to sprint_1
• All the changes related to functionality should be done here

• Push and pull operations should be performed using

  git pull origin sprint_1  and git push origin sprint_1
  

When the changes are done and sprint_1 has a stable code, it could be merged with other branch. If the code on sprint_1 has come a long way, it is advised to rebase the branch than merge to avoid conflicts or cherry picking.