Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @[email protected] meant.
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it
Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.
You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.
That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.
A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.
I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.
I know. Answered anyway because I thought of the same thing as you.
Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
I like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge. It’s also not obvious to beginners since pull is defaulted to fetch+merge.
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.
Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.
When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.
What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.
you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.
Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.
Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.
Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).
Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.
So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other?
Edit: no. Read wrong. I should probably watch a vid about it or something
I’ve been using merge, and I hate that I don’t even know what rebase really does
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
This diagram seems wrong to me. Isn’t the second image a squash merge? Also why would rebasing a feature branch change main?
The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @[email protected] meant.
the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it
Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).
deleted by creator
Facts. Force push belongs in Star Wars, and nowhere else.
Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.
You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.
That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.
A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.
Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.
I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using
git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.I know. Answered anyway because I thought of the same thing as you.
I like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge. It’s also not obvious to beginners since pull is defaulted to fetch+merge.
I’m relatively new to git and rebase looks like a mess to me? Like it appears to be making duplicate commits and destroys the proper history?
If you use rebase to get a more readable history, isn’t the issue the tool you use to view the history?
I guess I have to try it out a few times to get it.
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then
git statuswill tell you that the remote branch and your local branch have diverged by as many commits as you rebased.Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.
When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.
What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed
randomlychronologically, but rather related commits following one another.And of course, you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
The commits aren’t duplicated, but applied to the main branch. Since git has commit ids, they won’t be re-rebased either.
Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.
Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.
Atlassian does a fantastic writeup on this.
So kinda like as if you had kept your branch synced the whole time?
Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.
Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).
Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.
It’s really hard to create an analogy for this.
So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other? Edit: no. Read wrong. I should probably watch a vid about it or something
It inserts the master changes before the task branch ones.