This post has been moved to the Sturdy blog
Hey coders!
As you’ve noticed, we’re still exploring the fundamentals to the core workflow of Sturdy. This week we’ve made some larger changes to when changes are copied from a workspace
to a codebase.Let’s get into it!
Sharing a change with the team
Earlier in Sturdy, making a change and sharing it with your team was a two step process. First you had to “Create change” where a change would be staged in the workspaces own changelog, but not yet available in other workspaces. To move a change to the codebase, the change first had to be found in the changelog and “Landed”.
We didn’t like this workflow, as the actions that you had to take did not match the users intention of “I’m done coding this now, and want to share it with my team”. And honestly, it was just confusing. What does even “Land” mean? 🤷♂️
We want to build something that’s better than sharing and reviewing changes late and in large batches, which is common in many Git based workflows. Git in itself does not have any limitations on how large or small a commit must be, but it’s often not ergonomic or effective to make small and independent changes, as creating even a single PR often requires many commands and switching between the terminal (or GUI) and the web.
In Sturdy, sharing a change with the codebase and your team, is now one click (or two keystrokes) away! “Share now” takes your changes, and moves it to the codebase right away.
“Add to share later” prepares the change and places it in the workspaces own changelog, where you can change your mind about it, edit it, before deciding to share it.
I’ve been really happy with this improvement to the ease of use! Sturdy really is the easiest way for developers to collaborate on code.
Now, next topic:
Keyboard shortcuts
Graphical UIs are great, they allow you to discover the product and features that you didn’t knew existed, but when it comes to productivity, nothing can beat keyboard shortcuts.
This week we’ve started to add shortcuts to Sturdy, and have added three of them so far, as we’ve hinted in the screenshots above.
When creating a change, the change can be shared immediately with ⌘⏎. To share the change later use ⌘⇧⏎. If you make a change in error, the change can be undone with ⌘Z.
This is a good start, but we’re not done adding shortcuts just yet, there will be more shortcuts coming soon, especially to the workflow of selecting diffs to include in a change.
Change the description of a change
A changes description is now editable! 🤯 If you make a typo, or just want to add some more context to a change that you or a team mate has made, you can now edit it, even if it’s been shared with the codebase! I bet you Git can’t do this. ;-)
Ignoring changes to a file
One of the first features that we built in Sturdy, before we even bootstrapped
the project, was compatibility with.gitignore
. It was a great feature, but was a hidden gem.To make it easier to ignore files, and to make it easier to discover this piece of git compatibility, we’ve now added a “Ignore file” button in the file dropdown when making a change. Ignoring a file adds this file to the codebases root .gitignore file in one click.
It’s currently not possible to mark an entire directory, such as node_modules, as ignored through the web UI — but manually editing the .gitignore file works great now when you know that it’s possible to do so. :-)
Those are the highlights of this week. Have a nice weekend everyone, and we’ll see you again in next weeks post!
[Git: The equivalent of a unique branch and checkout]
[Git: A repository and it’s HEAD branch, that all workspaces are tracking]
Our first goal with Sturdy was to start developing Sturdy in Sturdy