TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

A Simple Explanation for Git Rebase

38 pointsby bradrobertsonabout 11 years ago

5 comments

golergkaabout 11 years ago
I tended to use git rebase constantly before pushing, until I realized how toxic it really is.<p>In the original commit before rebase everything seemed to be working; but someone changed something else in the code you were relying on without creating a direct conflict, and now all your rebased commits crash and burn. What&#x27;s worse, you discover it much later, when original commits are long gone, and instead of one merge commit being the easy traceable breaking point, you now don&#x27;t even quite remember which exact commits were rebased and have to check EVERYTHING.<p>Or, and with merge commit you could&#x27;ve easily just check it right there with simple tests before committing — no such convenient option for rebase.<p>The thing is, it&#x27;s a leaky abstraction. Rebase workflow tries to present things simpler then they really are, and you end up paying a price for it.
评论 #7596300 未加载
评论 #7596507 未加载
tunesmithabout 11 years ago
I just never find rebase very relevant because we&#x27;ll have team members collaborate on the same branch. If you want to collaborate on an in-progress story that has its own branch, you have to push your commits. You might be able to rebase on any commits you push into the branch, but when it comes time to merge the branch into the main line (which might have received several commits in the meantime), you have to stick with the timeline of those pushes, so you lose much of the benefit of rebase.<p>Not sure why the author says that is weird - I can&#x27;t think of an alternative if people are truly collaborating or pairing on a feature.
评论 #7599497 未加载
azinman2about 11 years ago
Thank you! I&#x27;ve always found this confusing and avoided it in my workflow. Assuming this explanation is correct, it makes a lot of sense and gives me a better workflow!<p>Are there any other useful ways to use git for a small team outside of pull and rebase? One thing that&#x27;s bugged me is undoing (possibly partially) previous pushed commits while keeping everything past.
评论 #7596072 未加载
klochnerabout 11 years ago
simple but unenlightening - I guess you hope no one asks you what&#x27;s really happening and just give up if you get a conflict.<p>It&#x27;s not that complicated - rebase applies your commits to another branch as if they were patches. Interactive rebase gives you the option of re-ordering&#x2F;removing&#x2F;editing those patches before they&#x27;re applied.
评论 #7597186 未加载
middleclickabout 11 years ago
Can anyone document a simple workflow with three branches: main (public), development (public) and feature (private).
评论 #7596236 未加载
评论 #7597264 未加载
评论 #7598169 未加载