Oh god I feel so called out. I wish I paid more attention to my commit messages but I’m usually too busy fixing the directory structure and refactoring. Sigh.
Master should just have the feature description commits, not the hundred commits it took to get there after refactoring the code for the 3rd time and pulling changes from master since it’s taken so long to get done.
Yeah I worked at a place like that, but it made sense because we were also expected to keep PRs small, so a good commit message for several squashed ones was perfectly fine.
I prefer that approach. We work with smaller tasks, so it makea more sense, plus it helps keep the master clean and if you want a more detailed view of the specific commits, you just have to click on the link to the PR. It’s a better way to organise it IMO
I’d love to like the desktop app, but I just don’t understand what it’s doing under the hood when I click a button. When I click an icon, is it syncing my changes up as it pulls down, it just pulling down? I guess point and click is more scary to me when prod is on the line.
If I may shill for a moment, that’s something I like about sublime merge - the buttons mostly map to git commands, and it has a nice log showing the commands it ran and their output.
This post title is misleading. The developer was working with Snap until Canonical didn’t allowed it anymore. He’s pissed with the policy enforcement which is strictly speaking commercial and as bad as Apple’s afaik…
Canonical has been taking bad decisions for quite some time now, and this developer was trying to reach Ubuntu users even while probably knowing these. Which makes sense, of course. The point being that this dev’s disappointment seems quite specific in these notes (against Snap), and imho he might work again towards shipping their app through Snap if he was allowed to. My comment compares Canonical to Apple, to give some context of where Canonical is at so many other idiosyncrasies (for example, I also heard other bad stuff about their H.R., in particular a way too lengthy hiring process.)
I think it depends what branch your local version of the repo is set to. If you’re already in master then it’ll push there, if you’re in a testing branch then you can push it straight to master instead by telling it to
I was being more evil than that, saying that if one is gonna push direct to main, might as well maximize the possible damage to everyone else’s branch.
Yup yup, usually you’re on a branch, sometimes a tag. I mean it’s all just pointers to references at the end of the day. I tend to treat Git like a story book, some folks still act like it’s SVN.
I use the right tool for the job, always. If all I need is to push a branch, then I’d rather use a UI that quickly shows me the changes in a nice diff layout. If I’m doing a pull request review and want to run it locally, I select the branch, pull, and go.
That said, when there are conflicts or tricky merges, or I want to squash a bunch of commits, anything like that, I’ll use the CLI.
It’s not about being above GitHub desktop or being an enlightened CLI user. It is about using the tool that is needed.
I’ve only been writing and releasing software for 15 years, what do I know.
That said, use whatever workflow fits you best! If that’s your hands never leaving the keyboard, rock on! If you instead write code like you’re playing an FPS, enjoy! We all do this because we like it, right? 😊
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.