- The project maintainer pushes to their public repository.
- A contributor clones that repository and makes changes.
- The contributor pushes to their own public copy.
- The contributor sends the maintainer an email asking them to pull changes.
- The maintainer adds the contributor’s repo as a remote and merges locally.
- The maintainer pushes merged changes to the main repository.
We are too small team to do this...
No step is explained
- Someone needs to create the central repository on a server. Central repositories should always be bare repositories.
$ ssh use@host git init --bare /path/to/repo.git
- Everybody clones the central repository. Each developer creates a local copy of the entire project.
$ git clone ssh://user@host/path/to/repo.git
Git automatically adds a shortcut called origin
that points back to the "parent" repository.
3. Chris works on his feature.
$ git status
$ git add <some-file>
$ git commit
- Wataru works on his feature.
- Chris publishes his feature.
$ git push origin master
origin
is the remote connection to the central repository that Git created when Chris cloned it.
6. Wataru publishes his feature.
$ git push origin master
will get an error, to prevent overwriting.
error: failed to push some refs to '/path/to/repo.git'
So Wataru needs to pull Chris's updates into his repository, integrate them with his local changes, and then try again. 7. Generate a non-bare repository by a bare repository
# Initialize
$ cd /path/to/staging.git
$ git init
$ git remote add origin /path/to/repo.git
#---
# Pulling a bare repository
$ cd /path/to/staging.git
$ git pull origin master
- (Optional) Pulling a bare repository automatically
Create a file
/path/to/repo.git/hooks/post-receive
#!/bin/sh
cd /path/to/staging.git/ || exit
unset GIT_DIR
git pull origin master
Also $ chmod 755 post-receive
(Japanese)http://morizyun.github.io/blog/how-to-git-review-book/
https://www.atlassian.com/git/tutorials/comparing-workflows/