4 ms·

And depending on your commits, you may need to solve conflicts several times (rerere alleviates this, though). Also, isn't this very basic? I thought pull --re

And depending on your commits, you may need to solve conflicts several times (rerere alleviates this, though). Also, isn't this very basic? I thought pull --rebase was one of the most basic commands everyone learned while getting acquainted with git.

ghshephard 7y ago
I started using git two years ago, and when I first asked all our senior engineers about it (after reading an article or two on HN about best practices) - the advice I was given was, "Never rebase." Among the more Jr. Engineers there was this feeling that it was a dangerous command that should be steered clear of, and the typical approach, of branching off of remote master, making changes, pushing to your branch, testing your code in the CI/CD environment (with appropriate unit/integration tests), and then issuing a PR to be reviewed and merged into master was the appropriate use of git. I don't think I've ever seen anybody (except very advanced git users) ever use "rebase" - so, no, I don't think I would consider it a basic command. Despite using git dozens of times every day, I don't believe I've ever rebased outside of a test-environment to see how it worked.
- cyphar 7y ago
  It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely wrong to say "never"). The reason why the Linux kernel has a no-rebase policy for maintainer trees is that thousands of developers base their work on the maintainer trees. Developers are constantly rebasing their work (either to update to the latest development branch by a maintainer, or to restructure and modify their commits with "git rebase -i"). Thus, rebasing maintainer trees would result in many developers having to deal with frustrating issues when they rebase (they have to curate which commits the maintainer has removed to keep with "git rebase -i"). It addition, maintainer trees get tested automatically and rebasing a tree invalidates all of the previous testing (so if you ask Linus to pull from you and the tree was just rebased, you're sending untested code and will get shouted at). Yes, you should never rebase master -- because there is guaranteed to be more than one user of master. But rebasing (for developers working on a feature) should be a very familiar thing to do -- unless you're working on a feature branch with someone else.
- northwest65 7y ago
  I'm far from an advanced user, but I use rebase fairly regularly for long running feature branches. As the parent branch continues along, I periodically rebase complicated feature branches so that I'm doing a number of small easy to handle conflict resolutions, rather than one almighty one at the end. I've never had any trouble, and I'd never considered it to be anything out of the ordinary or anything other than basic!
  - DuskStar 7y ago
    Huh. Personally, I merge master into my feature branches to keep up to date instead of rebasing - I find it helps the tree match the actual actions that were taken.
- darepublic 7y ago
  At my first job where git was used rebase was the norm. Never thought of it as more advanced just a different style of managing the commit history

ghshephard 7y ago

I started using git two years ago, and when I first asked all our senior engineers about it (after reading an article or two on HN about best practices) - the advice I was given was, "Never rebase." Among the more Jr. Engineers there was this feeling that it was a dangerous command that should be steered clear of, and the typical approach, of branching off of remote master, making changes, pushing to your branch, testing your code in the CI/CD environment (with appropriate unit/integration tests), and then issuing a PR to be reviewed and merged into master was the appropriate use of git. I don't think I've ever seen anybody (except very advanced git users) ever use "rebase" - so, no, I don't think I would consider it a basic command. Despite using git dozens of times every day, I don't believe I've ever rebased outside of a test-environment to see how it worked.

cyphar 7y ago
It's a bit frustrating that the whole "never rebase" thing has become a cargo cult -- because it's only correct in specific circumstances (thus it's completely wrong to say "never"). The reason why the Linux kernel has a no-rebase policy for maintainer trees is that thousands of developers base their work on the maintainer trees. Developers are constantly rebasing their work (either to update to the latest development branch by a maintainer, or to restructure and modify their commits with "git rebase -i"). Thus, rebasing maintainer trees would result in many developers having to deal with frustrating issues when they rebase (they have to curate which commits the maintainer has removed to keep with "git rebase -i"). It addition, maintainer trees get tested automatically and rebasing a tree invalidates all of the previous testing (so if you ask Linus to pull from you and the tree was just rebased, you're sending untested code and will get shouted at). Yes, you should never rebase master -- because there is guaranteed to be more than one user of master. But rebasing (for developers working on a feature) should be a very familiar thing to do -- unless you're working on a feature branch with someone else.
northwest65 7y ago
I'm far from an advanced user, but I use rebase fairly regularly for long running feature branches. As the parent branch continues along, I periodically rebase complicated feature branches so that I'm doing a number of small easy to handle conflict resolutions, rather than one almighty one at the end. I've never had any trouble, and I'd never considered it to be anything out of the ordinary or anything other than basic!
- DuskStar 7y ago
  Huh. Personally, I merge master into my feature branches to keep up to date instead of rebasing - I find it helps the tree match the actual actions that were taken.
darepublic 7y ago
At my first job where git was used rebase was the norm. Never thought of it as more advanced just a different style of managing the commit history