20

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.

nyzm
  • 2,607
  • 2
  • 21
  • 30
  • I've never actually tried this since it seems a bit convoluted but it could be achieved by setting up remote git access on each local computer no problem. (create a git user, add authorized keys, create a forked repo, etc) – Daniel Williams Aug 16 '13 at 04:46
  • Everything in that article seems like a standard workflow to me. I can't see any advantage of team members pulling changes from other peers. You *could* setup git servers on everyone's desktops, but that is a huge headache for no real improvement. Maybe you should tweet the author? I'll be following up on this one. – spuder Aug 16 '13 at 05:05

5 Answers5

4

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.

Bijendra
  • 7,429
  • 5
  • 32
  • 60
  • 3
    this is not what I am asking for. I know they can work on any branch by pushing to and pulling from a remote repository. – nyzm Aug 19 '13 at 03:01
  • 1
    It's not directly an answer to the question, but I upvoted it because it is actually much simpler to understand and set up. So if you can't wrap your head around the other workflow (or you can't convince your manager to go with it, or your IT department makes inter-developers pulls difficult with network settings), you can use this setup instead. Wouldn't scale to thousands of devs, but not bad. – Wildcard Dec 01 '15 at 00:52
4

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?

Community
  • 1
  • 1
Brent Bradburn
  • 40,766
  • 12
  • 126
  • 136
2

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.

Community
  • 1
  • 1
Gerardo Rosciano
  • 816
  • 5
  • 11
  • this is pretty close. what about macosx or linux users are in the team? – nyzm Sep 07 '13 at 16:16
  • @nyzm i know my comment is a little late to the game but windows is the odd man out, mac and linux are the same. But if you're using git bash to interact with git on Windows (I believe the bash terminal is packaged with Git, but it's been a while since I used Git one Windows so I could be remembering wrong), then the functionality will be the same regardless of which OS you're using – StormeHawke Aug 18 '14 at 13:46
1

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.

jthill
  • 42,819
  • 4
  • 65
  • 113
  • 5
    This would be more helpful with an explanation of `git daemon`. I have a feeling that command is the true answer to this question, but it's not explained in any answer currently posted. – Wildcard Dec 01 '15 at 00:53
1

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).
Bert Regelink
  • 2,576
  • 21
  • 17