4 ms·
Isn't that what feature or topic branches are for? Commit in your own little world, merge when you are ready to share.
by kawsper 7y ago
Isn't that what feature or topic branches are for? Commit in your own little world, merge when you are ready to share.
- dahart 7y agoYes, that is what feature branches are for. The policy I’m talking about is referring to when people share, not when they commit to a feature branch. Sorry, I did initially described it only as “commit”, so that was my fault, not yours.
- breck 7y agoBut a lot of teams prefer that you do rebases and have a flat commit history, rather than have merge commits (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch). I still think this a very cool back-of-the-envelope estimate though.
- srfilipek 7y ago> (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch) That's not the case with git. By default it preserves the original commit time.
- yesbabyyes 7y agoI think they may be talking about squashing several commits before rebasing, creating new commit(s).
- breck 7y agoYes, this is what I meant. It wasn't clear, thanks. Generally squashing all the feature commits in a branch into 1 atomic commit in master.
- kzrdude 7y agoIt just calls it author date (it records one commit date and one author date), and one of those is preserved by rebasing. :)