Howto Rename Git Master Branch

While Git uses the term master in the sense of “master record”, it’s clear that master as a term has connotations to master-slave methaphor which is both technically and historically inaccurate according to The Internet Engineering Task Force. Here’s how to rename Git master branch both in your local repository and on GitLab.

1. Rename Git Master Branch

First, rename master and push the change to origin, then update local references to this new name. (I’m using trunk here as the new name but you can use main or whatever you wish. Just change the commands accordingly.)

git checkout master git branch -m master trunk git push -u origin trunk  git branch --unset-upstream git branch -u origin/trunk git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/trunk

2. Change GitLab Default Branch (And Delete master)

Navigate to Settings > Repository and set the new default branch. (In GitHub you’ll find the same setting under repository Settings > Branches.)

Settings

Lastly you may want to delete the old master branch but you need to remove protected branch status from GitLab before being able to do that. Go to Protected Branches on this same Settings > Repository page and Unprotect the master branch if it’s protected. (Don’t forget to add the same protections back to the new branch!) Now we can delete the old master branch:

git push origin --delete master

Bonus: Change Default Git Branch For New Repositories

Since Git version 2.28 you can easily set the default branch name for all new repos with a simple command:

git config --global init.defaultBranch trunk

Congrats for participating in making the word just a little bit better place for all of us!

Weeknotes 35/2020

Many of my developer peers seem to have picked up the practise of publishing weeknotes. I’ve been meaning to do this for a long time, so here goes.

Shaping Up

I discovered Shape Up originally via Adam Wathan who posted absolutely brilliant Twitter thread about becoming a succesful independent maker. It took me a wihe to manage to actually read it, but now that I finally did, it left me with some good ideas about shaping up (pun intended) my own work practises.

Shape Up is a very Basecamp-y look on modern development workflow and work practises. It narrows down on an idea of a 6-week work cycle where the team works on a pre-planned (shaped) project with external phases for planning and also for bug-fixing (what they call cooldown). Reading this felt really good as it is very similar what I’ve been doing with many teams of various sizes for a long time now.

I’ve found out that with most agile teams the idea of a 10-day sprint that inludes design and retro phases are just way too short. It forces the work to be planned and scheduled too much from the top down and leaves the team very little time for independent organization. If the work is instead planned (shaped up) beforehand with a smaller and more experienced team, and there is a separate bugfixing (or cooldown) period after the actual work phase (which is longer than two weeks) the probability of succesful delivery grows drastically.

This is very interesting topic for me and I’ll propably write more about it in the future. With some new inspiration from these ideas I reorganized my near future personal work in a new way. I converted my monthly plan from two sprints into a one cycle with a proper Iteration Plan (idea stolen from VS Code team) that has just one properly shaped and planned goal and clear dates for work phase. My cycle lasts for three weeks after which there is a one-week cooldown for bugfixes and planning for the next cycle. This method lets me keep monthly release cycle and hopefully allows me to actually ship something every single release. I may report back on the success of this model in the future.

New Vue 3 + TypeScript Project Template

For my end goal of shipping a totally new Vue 3 + TypeScript powered frontend for Slipmat users and artists I need a good and tested base for which to build on. To experiment with this I started a new project from scratch to remake the current admin views which have become a bit of a dumpster fire.

I’m using Tailwind UI components as a base which makes getting started really easy and fast. Unfortunately all the components are based on very bright color themes so I’ve had to come up with my own dark color scheme as Slipmat needs to be dark by default. I spent a week with the initial design and refactoring some old API views to get some basic dummy data for developing. The end result looks pretty good as a starting point, I’m sure the final product will work out great. (This is just a proof of concept after all!)

Vue 3 is now in RC phase and using it with TypeScript feels really solid already. The tooling (devtools in particular) is lagging a little bit behind but it’s early days still. I’ve got the project base pretty much nailed, it has fully automated CI/CD pipeline with end to end tests with Cypress and Mirage JS with coverage monitoring that fails the build if coverage drops below 80%.

I’ve also tried to keep everything as lean and as close to native JavaScript as possible. Most of the usual go-to libraries have had a tough screening and for example Moment.js (70k) had to go in favor of Day.js (2k). So far I’ve managed not to load lodash either, although it might come back at some point as practicality beats purity. I might do a write up of these most used third-party libraries as well when I’m starting the final production projects.

Here’s the full list of my current dream stack that powers the new project:

JavaScript Search Engines

Proper search is something that I’ve never got time to build for Slipmat yet but especially for admin tools it’s very important. We do run Elastic on our backend stack but I wanted to investigate if I could whip up something very fast and totally in-browser so I studied few JavaScript search engines.

Turns out there aren’t that many serious contenders. There’s Fuse.js which is great for small datasets (say less than few thousands of objects). I’ve used it in the past for some projects but I wanted something a bit more serious for this. There’s also Lunr.js and Elasticlunr.js both of which are loosely based on Solr. These are serious search engines with lots of options for tweaking the results and proper indexing.

I ended up picking MiniSearch which is a tiny (6k min+zip) yet “proper” and modern search engine that has no external dependencies and can do all kinds of nice things like fuzzy matching, auto suggestions, field boosting and realtime index updating. It can also export and import the built index which makes the initialization very fast. I’m testing the system with a 2Mb json file that has few thousand latest instances of about every model one might want to search (offline) from the admin dashboard. The biggest overhead comes from downloading this first json. Initializing the engine takes about 300ms but when you save the index it shrinks to about 1,5Mb and initializing that only takes about 50ms. As an initial proof of concept the simple pre-warmed and cached json works well enough though.

I’m not yet sure if having a offline-capable frontend-only search is worth it when everything is already indexed in Elasticsearch but this was an interesting one-day experiment in any case. Here’s the search in action:

Search Demo

Okay so this weeks notes were a bit on the long side but hey, it’s been a while. But let’s try to do this again next week! In the meanwhile, find the RSS-feed and @Uninen on Twitter 🙂