4 ms·

If you're working in a group and structure your branches around releases (or really any logical way), you need to use rebase. It can be a pain in the ass but i

by lnguyen 14y ago

If you're working in a group and structure your branches around releases (or really any logical way), you need to use rebase. It can be a pain in the ass but it's the only way to guarantee that you're all consistently working from the same set of files/commits and that the your updates don't mix in other changes (aka chances for errors/regression). See http://gitguru.com/2009/02/03/rebase-v-merge-in-git/ http://gitguru.com/2009/02/03/rebase-v-merge-in-git/

pnathan 14y ago
I don't understand how rebasing is usable in a corporate environment (with a central server that's backed up) unless you have some sort of temp repo that you plan to squash down and send to the canonical repo.
- lnguyen 14y ago
  There shouldn't be any issue about where rebase is usable versus merge. It's more process than technical except if you're expecting git to handle things right out of the box. None of these arguments are anything new: Any one who's worked with ClearCase should recognize them [1]. Read up on the UCM lifecycle. [1] Software Configuration Management Strategies and Rational ClearCase (1st edition: http://www.amazon.com/Software-Configuration-Management-Strategies-ClearCase/dp/0201604787 http://www.amazon.com/Software-Configuration-Management-Stra...). And yes, it's from over 10 years ago...
- wanderr 14y ago
  Remember, git's major strength is its distributed nature. Forking and branching are the easiest thing in the world to do. What we do here is, developers work in a fork and/or a topic branch, when they think it is complete the code goes through a review and when it's ready to merge, is rebased onto the latest canonical repo/branch before being merged in. Clean, linear history, no problems with corporate environment. Am I missing something about the perceived problem?
  - lnguyen 14y ago
    I'm going just a bit pedantic on this part: "when it's ready to merge, is rebased onto the latest canonical repo/branch before being merged in" should read "when it's ready to merge, we rebase the local development branch to the latest canonical repo/branch, resolve the rebase merge issues, and then merge the changes into the canonical repo/branch" It's probably what you're doing but just saying it more precisely in the use of git (and SCM) terminology.
- grayrest 14y ago
  You do feature based branches that get rebased against master on a regular basis and push -f your dev branch in the evening so your changes are backed up. When two devs are working on the same branch they coordinate via chat who (or whoever comes in first) does the daily rebase and the other does a fetch and hard reset. For when a significant fraction of the team is working on a branch, you just have a running branch/merge. Everything works off the central repo and there's a git hook to prevent push -f to master.
  - pnathan 14y ago
    It's the push -f that I was missing. That would solve my point. :-)

by lnguyen 14y ago

pnathan 14y ago

I don't understand how rebasing is usable in a corporate environment (with a central server that's backed up) unless you have some sort of temp repo that you plan to squash down and send to the canonical repo.

lnguyen 14y ago
There shouldn't be any issue about where rebase is usable versus merge. It's more process than technical except if you're expecting git to handle things right out of the box. None of these arguments are anything new: Any one who's worked with ClearCase should recognize them [1]. Read up on the UCM lifecycle. [1] Software Configuration Management Strategies and Rational ClearCase (1st edition: http://www.amazon.com/Software-Configuration-Management-Strategies-ClearCase/dp/0201604787 http://www.amazon.com/Software-Configuration-Management-Stra...). And yes, it's from over 10 years ago...
wanderr 14y ago
Remember, git's major strength is its distributed nature. Forking and branching are the easiest thing in the world to do. What we do here is, developers work in a fork and/or a topic branch, when they think it is complete the code goes through a review and when it's ready to merge, is rebased onto the latest canonical repo/branch before being merged in. Clean, linear history, no problems with corporate environment. Am I missing something about the perceived problem?
- lnguyen 14y ago
  I'm going just a bit pedantic on this part: "when it's ready to merge, is rebased onto the latest canonical repo/branch before being merged in" should read "when it's ready to merge, we rebase the local development branch to the latest canonical repo/branch, resolve the rebase merge issues, and then merge the changes into the canonical repo/branch" It's probably what you're doing but just saying it more precisely in the use of git (and SCM) terminology.
grayrest 14y ago
You do feature based branches that get rebased against master on a regular basis and push -f your dev branch in the evening so your changes are backed up. When two devs are working on the same branch they coordinate via chat who (or whoever comes in first) does the daily rebase and the other does a fetch and hard reset. For when a significant fraction of the team is working on a branch, you just have a running branch/merge. Everything works off the central repo and there's a git hook to prevent push -f to master.
- pnathan 14y ago
  It's the push -f that I was missing. That would solve my point. :-)