#VersionManagement for binary files is hard; often we just consider them #blobs and give up. We use #DSLs to get rid of the blobs. Version control systems were designed for textual formats. No trees, no binaries, just plain text. At our customers we’ve often designed DSLs specifically to thrive in a version control system.

This post is the start of a three-part series. We’ll present how we’ve designed these DSLs, the benefits you’ll get, and how we migrated from existing systems to the DSLs.

https://www.swat.engineering/news/dsls-as-a-version-management-enabler/

How I Manage Node & Package Manager Versions:

https://dev.to/michalbryxi/how-am-i-managing-node-package-manager-versions-3904

A clean Git history is the key to successful teamwork and quick bug fixes. Errors can only be successfully tracked down if it is always possible to trace when and where code was changed by whom and for what reason.

However, in the rush of the battle, the changes that are packaged in a commit are sometimes not taken very seriously. Who has never experienced this? A change that is actually unrelated to the current work package has made it into the commit because the file has already been saved temporarily.

The solution: With an "interactive add" (git add -i), you can pack partial changes ("hunks") into a commit and specify line by line what should be included in the next commit.

"Staging patches": https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging