I have had Pluralsight for many years now and I agree with you. In some cases they have excellent courses, but I sometimes find the content outdated. I plan to explore O'Reily's platform next year. They seem to have a different set of resources and are comparable in price.
81
Google Cloud accidentally deletes cutomer’s online account due to ‘unprecedented misconfiguration’
(www.theguardian.com)
I don't think Git has built-in support for that, but there seems to be some syntax/language aware diff tools that can be configured as the difftool.
I see. Good luck with your search. Would be great if you could update the thread once you settle on a solution.
Not sure I understand the use case and why something like VS Code's Git UI (or some other GUI) cannot solve the problem. Why does it need to be web-based, for example?
I believe there is already a browser add on for this. Cannot remember the name right now.
Edit: I think this should be in Lemmy core.
Interactive rebase is used to organize (squash, drop, reorder) commits and with some experience is totally painless. Would definitely recommend watching a few videos about it.
I would add Ars Technica to that list and call it a day.
For programming I follow YouTube channels of the conferences relevant for my tech stack (YouTube natively supports RSS). They are generally 1 hour talks but it's a great way to stay up to date.
Maybe my explanation was complicated, but what I describe is not time consuming. It takes at most a few minutes to do all of the things I mentioned. The difficult part is discipline of keeping refactoring separate. Once that's done, the rest is trivial. And not all work include refactoring. That's even easier then.
The way I commit on my private branch is different than how I merge those commits to the main branch. When working on the private branch, things can get messy and if they do, I just try to keep certain things separate from each other (refactorings and bug fixes should not go into the same commit). Once the work is done, I do a interactive rebase to tidy things up and then merge them afterwards. Sometimes the changes are not that much and it becomes a squash commit. I would definitely refrain from creating 100 (insignificant and possibly back-and-forth) commits on the main branch.
I cannot answer the technical question as I don't have enough experience with that. But I think sites like reddit mostly don't care about search. They probably think: "People can use google if they want to search."
Apart from the historical value, the most important part of this article now is the "Note of reflection" added 10 years after it's inception:
I don't think this work flow is relevant any more even for teams that don't do CD, to be honest. It was a messy work flow to begin with and I haven't seen it applied successfully in practice.