3 ms·
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
by 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 agoI'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.