[...]Setting up Rails 3 on Rackspace Cloud Servers « Cowboy Coded[...]…

[...]Setting up Rails 3 on Rackspace Cloud Servers « Cowboy Coded[...]…

http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
Retrieving http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
error: skipping http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm – transfer failed – Unknown or unexpected error
warning: u 0×1768540 ctrl 0×17698b0 nrefs != 0 (download.fedora.redhat.com http)

This would be exactly how the buddies in the car shops feel. A few years ago they could get every engine running with their metal tools and now they are most of the time phoning after the right diagnosis tools or the manufacturers experts without getting dirty at all. Times are changing, that’s for sure.

It is really personal preference and I guess depends on what kind of team you are working on when it comes to git workflows. I commit often locally and I usually prefer a commit for each file, unless they are closely related and I can describe it in one message. I like to describe what I did to each file so I have a nice history with description, but some people probably just commit a bunch of files at once with a general commit message. On some larger open source projects I think they prefer that you fork the repo, make your changes and issue all of the changes in a single commit, so there is a single “diff” that the repo owner can anlalyze without having to pick through a ton of files.

As far as pushing goes, its also personal preference. Most of the time, I will only push when a change is complete, tests are passing, and I know its not going to break something else in master (or whatever feature branch I am using). Every now and then I push half-complete changes if I am going from work computer to home laptop, but thats really the only time. If you are working with a team, I would assume the only want you to push when it is complete and tests are passing.

Local commit messages ARE added when you merge a branch. In github, they will be inserted into the timeline on the day you made the commit/push (not necessarily same day as merge). There is also a separate commit message for the merge.

Again, I probably don’t use git the way most people do since most of my projects are solo, and I am by no means a git expert… I know enough about it to make it work for my workflow. Google something like “git workflows” and you will probably find a workflow that fits your project/style

Maybe my question from last post was a bit “dumb” so you misinterpreted it, but as I now understand one would commit locally every now and then and only push if a “usable” (no syntax errors, finished methods) version.

I guess local commit messages are then not merged into the head branch but only the changes from the push, but I will study the rails repo and stuff for myself now…

When you are creating a new feature, you can create a new branch in git and work on the code from that branch without affecting the master branch (or other branches). Check out how Rails does this. They have a separate branch for each new minor release -> https://github.com/rails/rails (Switch Branches dropdown). That way, they can work on the latest and greatest in the master branch and still have branches for any patches or features that need to be added to the older versions.

You can work in the branch and make your changes, and even deploy from that branch if you want to. Or you can merge the changes into the master branch after you are done. Also, look into creating tags for each milestone so you can rollback to one of the tags if you need to. Branching and tagging keeps you from having to make changes and then do a rollback. You can simply re-deploy with a different tag or branch.

More info here:

Branching and merging
http://www.gitready.com/beginner/2009/01/25/branching-and-merging.html

SVN to git
http://yehudakatz.com/2010/05/13/common-git-workflows/

even git works… i thought of the following “tactics”:
local programming, local testing, push to server, hoping that it would work otherwise rollback. proceed from point one.

I got one problem though: In the past I often had to “try&error” because of server configuration issues, which got me to revision 98 before the server was running (with svn and a fcgi-approach which is is not supported for rails3 by hostingrails as the support wrote a few hours ago btw).
How do you handle your commits when working/testing on “one feature” for several days? Only commits when the “feature” is ready?

I’m thinking of a situation like locally making substantial changes, adding gems and stuff, and then online: bam, error, nothing works because one of the three gems you added probably dislikes the current ruby version or your local rvm version is newer or stuff…

you would have to roll back the git and then recommit in smallest possible parts, wouldn’t you? That would definately screw up the commit history :/