I always try to follow best practices, so I’m in the process of learning
Git
since the Rails community seems to have favored that over Subversion (I
know
the basics of svn as it stands right now). I have to admit, I like the
idea
of working locally and then pushing it up when I’m done, instead of
always
having to push it to a central server.
The one thing that confuses me, however, is that with Subversion you
have
your central dev/staging server, and you commit and checkout to/from
that,
which enables you to use continuous integration or similar to make sure
that
the build is working. I like the distributed model of Git, but I’m
disturbed that there’s no “main” server. I guess you can set up the
server
in the same way and push/pull to/from it just like subversion when
you’re
ready, but wouldn’t this cause issues if I do several commits on my
local
version (say, I’m working on implementing a new module) and then push it
to
my staging server? The revisions would be different because my local
branch
has more commits (for individual pieces of the module) and the “master”
repository only has one (the finished module itself). That sounds like
a
good idea, since you can do several mini-commits locally, then push it
all
up to the staging environment when the module/task/feature is complete.
I don’t see how this works within Git, unless Git doesn’t care about the
revisions. Am I getting myself confused over nothing here?
I’ve used Git a little in the past, but use Mercurial now. They are
essentially the same in how they work though. When you push to the
remote repository, all of your changesets get pushed. So if you’ve made
no changes on the remote side, after a push, your git list should look
exactly the same.
Peace,
Phillip
So it doesn’t matter if I commit 6 times locally, and then do one
“mega commit” to the server? I ask because I want to set up a staging
server to test my application, but until I get that done I’ll use my
local repository.
So, say I’m working on a module for my application. I make sure that
my git is up to date from the staging server’s repository, and begin
to work:
(Local)
Commit #1 - Generated model for Foo and created initial migration
Commit #2 - Model specifications for Foo
Commit #3 - Controller specifications for Foo
Commit #4 - Created views for Foo#index, Foo#show, Foo#new
At this point, the Foo module is finished. My local repository has
had four separate commits, while the staging server hasn’t been
touched. It won’t cause any syncing problems if I push these changes
up to the staging server’s copy, say with the message “Adding
completed Foo module and specifications”? I could have sworn in SVN
this would foul things up because the local copy would be at a
different revision number (4 commits vs. 1).
If this isn’t an issue in Git, then I have nothing to worry about 
You’ve got the idea. Keep in mind that you don’t do a “mega commit” to
the remote repository. In DSCM, no repository is any more or less than
any other. You do your commits to your local, and when you’re satisfied
that what you have is ready to be synchronized with the remote, you do a
push. If there are no changesets in the remote repository, it’s just a
matter of your local changesets getting pushed out. There won’t even be
a message for it.
No, no problems. That’s what DSCM is all about. If there were changesets
in the remote, Git would ask you to resolve any conflicts. If there are
no conflicts, Git will just merge the files for you.
Enjoy.
Peace,
Phillip