On 21 April 2012 08:34, David Gowers (kampu) 00a...@gmail.com wrote:
On Sat, Apr 21, 2012 at 3:26 AM, Ralph Versteegen teeem...@gmail.com wrote:
I found this pretty confusing too, and I'm still not entirely
comfortable working with remotes.
But I'll point out (though this is getting into
On Sat, Apr 21, 2012 at 05:56:10AM +1200, Ralph Versteegen wrote:
Are you planning on using git-svn? If so, you should say so, it
completely changes the workflow. No merging or remotes, lots of
rebasing.
Yes, I was thinking of that.
In the long term, I would like to retire the gilgamesh
On Sat, Apr 21, 2012 at 3:26 AM, Ralph Versteegen teeem...@gmail.com wrote:
I found this pretty confusing too, and I'm still not entirely
comfortable working with remotes.
But I'll point out (though this is getting into advanced territory)
that there are usually *three* copies of a remote
I figure if I am ever going to learn to use git, I need to learn how to
replicate my existing svn usgae patterns with git. I have been told many
times that git's functionality is a superset of svn's so this should be
no problem.
My trouble is that every tutorial I can find, even the ones that
The thing to remember about git is that it's all about branches. You
are always on a branch, usually called master (but that varies, of
course). So, I will use master as the branch name below.
To update your repo, you need to do this:
git fetch #pulls changes from origin
git merge origin/master
Whoops, I am remiss, and forgot a few things:
- origin is what is known as a remote. This might be a
colleague's computer, or it might be a central server (I only have
experience with the latter). By default, the remote is named origin.
So, when you're dealing with remote branches that live on
git pull is a shortcut for git fetch git merge
origin/CURRENT_BRANCH_HERE in case you weren't aware.
On Apr 18, 2012 1:08 PM, Mike Caron caron.m...@gmail.com wrote:
The thing to remember about git is that it's all about branches. You
are always on a branch, usually called master (but that
