git is a SCM and should not be on production systems.
instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments.
you should also not compile JS/CSS etc on production system that is what the build server is for.
anything installed on a production system should be 'required' for the app to actually run.
-
that said, you can use capistrano (and other tools like this) to update 'demo' environments and dev environments (with git) however the actual TEST and STAGING environments should mirror the PROD environment (packaging).
Please use rebase... but only if you understand it!
Do not commit to your commits...
I experiment on branches... I use commits as stashes... I end up with 100s of local branches...
-
Only rebase non-shared commits.
Normally people say "dont rebase pushed branches" but what if you merged your local branch into a different branch which is pushed? them commits are already shared...
Then again.. I would rebase branch X but because branch Y was branched off X I also rebase branch Y onto the new X.
-
I even rebase pushed branches, because they are _my_ branches.
-
To those who say rebase is a "lie".. I say don't commit to your commits... do you commit each time you hit the keyboard? well that is history which _could_ be captured for the sake of useless history...
-
Before merging cleanup your branch so it is clear what the branch is doing and add in more useful commit messages (use the body of the message, not just the subject).
-
Do you end up with a load of local changes which are hard to give clear commit messages to? so you end up doing "git add ." instead? then you should be committing more often.
Personally I think its better using the CLI for git.
I commit very often however I rewrite the commits. In other words, I mess with my history and it is a good thing (My commits ain't final, in other words... "I do not commit to my commits").
In SVN I try not to commit too often because I do not want to commit (publish) changes which I may not want to keep.
With git I commit very often in stages. Then I can remove them or change them at a later stage. If I do not do this I will end up with a load of files (e.g. 50+) which has been modified and either I commit them all in one (bad) go or try and separate out each step I've taken the past 12 hours and do decent commit messages (good).
Of course you could commit very often, create new commits to fix errors you've done in recent commits (rather than rewriting history). You could also merge master into feature-x everyday (rather than rebasing), but then you'd have history which looks like chaos and hard to follow.
-
Honestly, when I started git I was lost (first VCS I learnt). Until one day I figured out how simple git is to use.
1.
`git pull` = fetch + merge
If the merge has conflicts, then you got to solve the conflicts and do the commit manually (entering the commit message)
If the merge doesn't have conflicts, then the merge commit is automatic.
2.
`git commit -m "foobar"` will commit the files from the stage/index
`git commit -am "foobar"` will commit all the modified files (it will ignore untracked files)
Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do.
"Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public.
Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane.
Don't commit unless your ready to commit? Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.
instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments.
you should also not compile JS/CSS etc on production system that is what the build server is for.
anything installed on a production system should be 'required' for the app to actually run.
-
that said, you can use capistrano (and other tools like this) to update 'demo' environments and dev environments (with git) however the actual TEST and STAGING environments should mirror the PROD environment (packaging).