I personally never rebase. It always seems to have some problem. I’m surely there’s a place and time for rebasing but I’ve never seen it in action I guess.
My biggest issue with GitHub is that it always squashes and merges. It’s really annoying as it not only takes away from commit history, but it also puts the fork out of sync with the main branch, and I’ll often realize this after having implemented another features, forcing me end up cherry picking just to fix it. Luckily LazyGit makes this process pretty painless, but still.
Seriously people, use FF-merge where you can.
Then again, if my feature branch has simply gone behind upstream, I usually pull and rebase. If you’ve got good commits, it’s a really simple process and saves me a lot of future headaches.
There’s obviously places not to use rebase(like when multiple people are working on a branch), but I consider it good practice to always rebase before merge. This way, we can always just FF-merge and avoid screwing with the Git history. We do this at my company and honestly, as long as you follow good practices, it should never really get too out of hand.
Yeah, I am. However GitHub, being the biggest Git hosting provider and all that, makes you use merge commits. FF-merges must be done manually from the command line. While this definitely isn’t a problem for me, many people out there just don’t care and merge without a second thought (which, as I said in my comment, results in having to create a new branch and cherry picking the commits onto there).
Sounds like I just gotta get better with rebasing. But generally I do my merges clean from local changes. I’ll commit and push, then merge in, push. Then keep working. Not too hard to track but I’ve found it’s the diff at MR time that people really pay attention to. So individual commits haven’t been too crucial.
(I’m also a fan of rebasing; but I also like to land commits that perform a logical and separable chunk of work, because I like history to have decent narrative flow.)
If your cherry-pick doesn’t run into conflicts why would your merge? You don’t need to merge to master until you’re done but you should merge from master to your feature branch regularly to keep it updated.
I’ve always merged. Rebase simplifies the history graph, but realistically I can’t think of a time where that has been important to me, or any of the teams I’ve worked with.
Maybe on some projects with a huge number of concurrent branches it becomes more important, probably less so for smaller teams.
I try to structure my commits in a way that minimizes their blast radius, which usually likes trying to reduce the number of files In touch per commit.
For example, my commit history would look like this:
Add new method to service class
Use new service class method in worker
And then as I continue working, all changes will be git commit--fixuped to one of those two commit’s hashes depending on where they occur.
And when it’s time to rebase in full, I can do a git rebase master --interactive--autosquash.
OK. Query.
Rebase or merge into current?
I personally never rebase. It always seems to have some problem. I’m surely there’s a place and time for rebasing but I’ve never seen it in action I guess.
Merge commits suck.
My biggest issue with GitHub is that it always squashes and merges. It’s really annoying as it not only takes away from commit history, but it also puts the fork out of sync with the main branch, and I’ll often realize this after having implemented another features, forcing me end up cherry picking just to fix it. Luckily LazyGit makes this process pretty painless, but still.
Seriously people, use FF-merge where you can.
Then again, if my feature branch has simply gone behind upstream, I usually pull and rebase. If you’ve got good commits, it’s a really simple process and saves me a lot of future headaches.
There’s obviously places not to use rebase(like when multiple people are working on a branch), but I consider it good practice to always rebase before merge. This way, we can always just FF-merge and avoid screwing with the Git history. We do this at my company and honestly, as long as you follow good practices, it should never really get too out of hand.
You are aware you’re talking about two different pieces of software?
Yeah, I am. However GitHub, being the biggest Git hosting provider and all that, makes you use merge commits. FF-merges must be done manually from the command line. While this definitely isn’t a problem for me, many people out there just don’t care and merge without a second thought (which, as I said in my comment, results in having to create a new branch and cherry picking the commits onto there).
You should check out the repo options on GitHub. It most definitely supports rebase merges, and you can disable other merge types if desired.
Sounds like I just gotta get better with rebasing. But generally I do my merges clean from local changes. I’ll commit and push, then merge in, push. Then keep working. Not too hard to track but I’ve found it’s the diff at MR time that people really pay attention to. So individual commits haven’t been too crucial.
What you do is create a third branch off master, cherry pick the commits from the feature branch, and merge in the third branch. So much easier.
That’s called rebasing
for some reason it’s easier than normal rebasing though
Have you tried interactive rebase (rebase -i)? I find it very useful
Yeah, but then you deal with merge conflicts
You can get merge conflicts in cherry picks too, it’s the same process.
rerere is a lifesaver here.
(I’m also a fan of rebasing; but I also like to land commits that perform a logical and separable chunk of work, because I like history to have decent narrative flow.)
If your cherry-pick doesn’t run into conflicts why would your merge? You don’t need to merge to master until you’re done but you should merge from master to your feature branch regularly to keep it updated.
Git is weird sometimes.
This is actually genius. Gonna start using this at work.
It only matters if you want to be able to use the commit tree and actually find something. Otherwise, there’s no harm in using merges.
I’ve always merged. Rebase simplifies the history graph, but realistically I can’t think of a time where that has been important to me, or any of the teams I’ve worked with.
Maybe on some projects with a huge number of concurrent branches it becomes more important, probably less so for smaller teams.
I try to structure my commits in a way that minimizes their blast radius, which usually likes trying to reduce the number of files In touch per commit.
For example, my commit history would look like this:
And then as I continue working, all changes will be
git commit --fixup
ed to one of those two commit’s hashes depending on where they occur.And when it’s time to rebase in full, I can do a
git rebase master --interactive --autosquash
.This is the way! Small commits with descriptive commit names, then just fixup into a few feature commits. Makes rebase a breeze.
Rebase. Merge into current leaves merge commits in the dev branches.