GIT workflow w/ multiple workstations and a centralize server
Ok, a few things I’m not quite sure about.
- I have a “bare” repo on a VPS in a remote DC.
- I have a workstation at work that I also code on.
- I have a workstation at home that I also code on.
1 – When I set up my initial repo on one of my workstation (i think Git calls this the master), should I check out and work from a different directory? Like subversion.
2 – When I want to work on the code at work, I’m confused, how do I go about making commits to the LOCAL repo on my work desktop and then at the end of the day, push my changes to the “bare” repo on my VPS so that I can pull the updates to my home desktop.
I tried using clone but every push I make from my home desktop ended up w/ me pushing the changes back to the remote repo.
2 Solutions collect form web for “GIT workflow w/ multiple workstations and a centralize server”
master is git’s default name for the main branch of a repository. It does not refer to the entire repository, but to that one line of development. You don’t need a separate working directory – the general idea of local git development is to work in the directory, commit changes to the repository, then push them upstream as necessary.
2 – You should have a remote in both your home and work repos pointed at the bare VPS repo. If you created your repo by cloning the VPS repo, it will be ‘origin’. Pushing to and pulling from origin are the defaults, so this is why your pushes are going there. This is the designed behavior – there’s a good chance that when you clone a repo, it’s the one you want to get updates from and push your changes back to.
I would suggest having both home and work treat the VPS repo as origin. You can then push to and pull from it on each computer when necessary, simply using
git push and
git pull. If one of your repos isn’t already set up this way, you could either reclone the VPS repo to do it automatically, or use
git remote add origin <url-of-VPS-repo> git config branch.master.remote origin git config branch.master.merge = refs/heads/master
The last two lines let git know that you would like your master branch to be associated with the master branch on the origin remote (your VPS).
In Git you can (and usually should) switch branches “in place”. For example if you are on branch ‘master’, and want to start working on branch ‘devel’, you can simply use
$ git checkout devel
and your working area would reflect branch ‘devel’. You need usually to be in a clean state, i.e. do not have uncomitted changes.
As to setup between “work”, “home” and “bare” repositories:
First, a matter of configuration. I’ll assume there that both on “work” and on “home” computer there is configured “bare” (or whatever you name your bare repository), with configuration that looks like the following (you can use “git remote add” to create it):
[remote "bare"] url = email@example.com:/path/to/repo.git fetch = +refs/heads/*:refs/remotes/bare/* push = refs/heads/*:refs/heads/*
There can be other remote configuration, for example about tags (e.g.
fetch = +refs/tags/*:refs/tags/* etc.), but I am omitting it for simplicity.
Second, let’s assume that you are working on branch ‘master’, and uou have the following configuration for such branch both in “work” and “home” repositories:
[branch "master"] remote = bare merge = refs/heads/master
You can of course have similar configurations for other branches.
Let’s now examine some example sessions. You are either at “work” or at “home”.
First thing you should do before starting work is to get updates from the “bare” repository. I’m assuming here that you are on ‘master’ branch. You can do that using “git pull bare”, or with above branch configuration simply “git pull”:
$ git pull bare Updating 8818df8..9ad6770 Fast forward foo | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
“Fast-forward” means here that “bare” repository is in advance of the repository you are working in (and tat you don’t have any changes that are not in “bare” repository). If you are working either from “work”, or from “home”, but not on those simultaneously, this should be the situation you get.
Now do some work (this is an example session only):
$ edit, edit, edit $ git commit -a $ git add somefile $ git commit -a $ git commit --amend
Note that you better finish your work so that there are no uncomited changes, but it is not a strict requirement. If you leave some uncomitted changes, you can finish commit before “git pull”, but then you wouldn’t get fast-forward but a merge. Or you can use “git stash” to stash away your oncomitted changes, and then apply stash (unstash) them after pull.
After finishing your work, you push your changes to the “bare” repository, so you would be able to access your work in other repository.
$ git push bare Counting objects: 8, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 493 bytes, done. Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. To firstname.lastname@example.org:/path/to/repo.git 9ad6770..4230584 master -> master
I hope that such example would help.