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.
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’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.)
That is absolutely not what rebasing does. Rebasing rewrites the commit history, cherry picking commits then doing a normal merge does not rewrite any history.
I’m sorry but that’s incorrect. “Rewriting the commit history” is not possible in git, since commits are immutable. What rebase actually does is reapply each commit between upstream and head on top of upstream, and then reset the current branch to the last commit applied (This is by default, assuming no interactive rebase and other advanced uses). But don’t take my word for it, just read the manual. git-scm.com/docs/git-rebase
“Reapply” is rewriting it on the other branch. The branch you are rebasing to now has a one or multiple commits that do not represent real history. Only the very last commit on the branch is actually what the user rebasing has on their computer.
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.
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.
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).
Always merge when you’re not sure. Rebasing rewrites your commit history, and merging with the squash flag discards history. In either case, you will not have a real log of what happened during development.
Why do you want that? Because it allows you to go back in time and search. For example, you could be looking for the exact commit that created a specific issue using git bisect. Rebasing all the commits in a feature branch makes it impossible to be sure they will even work, since they represent snapshots that never existed.
I’ll never understand why people suggest you should default to rebasing. When prompted about why, it’s usually some story about how it went wrong and it was just easier to do it the wrong way.
I’m not saying never squash or rebase. It depends on the situation but if you had to pick a default, it should be to simply merge.
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.
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.
Because some scammers are stupid enough to believe that they'll get a certain amount of money (usually very large) from scambaiters. It's even more hilarious when they fail to catch on (after a long period of time) to the fact that they've been led on.
At least there’s Windows Search to bring your system to its knees by indexing everything constantly in the background, only to be both terribly slow and unable to find anything at all when you actually need it.
I depend on Voidtools’ Everything search, which actually finds stuff.
The Windows Scan app is particularly bad at this. When you scan a document, it saves the scan as a PNG in PicturesScans. This is a sensible place to save scans by default, but it doesn't tell you where. It just says it was saved. There's a button to view it, but this just opens the scan in the Windows Photos app, which (at least, last I checked) doesn't have an option to view the full path of the picture you're viewing or open the folder it's in!
They want you to access everything through search and recently accessed because its so intuitive. It’s like they want computers to be as hard to use as possible for people who need to do actual work on many projects in any sort of organized way.
Also, now that IT has integrated everything with OneDrive, I routinely have to wait for my own files to be redownloaded before accessing them.
Oh, looking at the Windows 11 Photos app real quick, I see the path is shown under the file info tab at the top. That's nice! I don't think this was shown anywhere in the Windows 10 version, but again, it's been a while since I've checked.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.