If you are going to branch every day as you begin your work, rebasing is a useful alternative to merging when you complete your task. You get the benefits of separation and the optionality of throwing away your branch if you choose, but you also keep the commit logs a bit easier to follow.
Rebasing definitely keeps the logs cleaner. Set up branches to rebase automatically with 'git config --global branch.autosetupbase always':
[branch]
autosetuprebase = always
Neat introduction to git, but it suggests using the "git commit -a -m" option, which is not only (edit: partially) redundant with the "git add ." command it recommends using beforehand, but actually interferes if you're trying to make a more selective commit.
The -a switch for the commit command will only add changes from all files listed in the index. "git add ." will add changed files that are in the index and those that are not. So they are not redundant commands.
Huh? They are redundant if you run them in succession. If you've just added all changes to the index, there is no need to use the -a option to commit unstaged changes to files in the index.
You're right about them being redundant if run in succession. Fixed in the post, thanks!
Use Buildmeister! My co-worker wrote a cool little tool wrapping this common workflow up so you can have single line deploys to staging that merge bug/feature branches.
Good introductory article. I never thought about branching even on smaller features (only do it for big ones) but it makes sense if you need to fix something critical and you're not finished your feature.
git branching is so simple I guess it makes sense to do so :)
.. I feel like I've lost 10 secs reading this. I mean, there are so many git workflow and tutorial, this one is like the first 2 lines of a good one but extended to a full page. Hacker News or Nooby News ? Yes down me, thanks, I'm used to it.