The value of Promises in Javascript cannot be overstated. They are used everywhere, helping to navigate the asynchronous maze that comes ...
JavaScript Async PromisesIf you have been working with an icon set and noticed that your icons are not vertically centered, then you are not alone. I was working ...
CSS UI/UXWith the release of our CSS Framework, Platform UI, it might be fun to actually build something with it! At RitterIM, we have an interna...
CSS Frameworks Static SitesIt’s been a few years, several great people, an awesome company, and a cool thing we made 😀 Once upon a time, we had a mixed bag of fram...
CSS Frameworks RIMdevI’m a huge fan of animation on the web, especially when it comes to user interaction. A simple way to include such a thing on webpages is...
CSS SCSS JavaScript UI/UX frontendI dedicate this blog post to all the QA testers that expose all the flaws in my code. For a few years now I thought I had it all figured...
CSS SCSS Mobile UX UI/UX frontendOne of the perks being with Ritter, and on the dev team, is you can choose the hardware that makes you happy and productive! Team members...
macOS RIMdevAs a technical writer, I create software documentation. But many times, I find myself looking at in-product copy and wondering about cont...
Documentation Technical writing UX writing Content designDocs and contextual help We recently started a push towards integrating Docs content into our software platform. The goal is to pull in...
Documentation Hugo XML RSSHave you ever wanted to change the value of a Sass variable based on screen size, a state, or for any other reason that might require cha...
css SassWe often use GitHub to create a compare view, and list pull requests (PRs) for releases. However, GitHub limits the number of commits you...
Documentation GitHub GitUsing our Hugo-based documentation site, we typically publish release notes once per week. My usual process includes the following: M...
Documentation Hugo ArchetypesAs someone who basically gets by when it comes to writing Javascript, I tend to look at things from a “I bet I could do this with CSS” st...
CSS SCSS Mobile UX UI/UX frontendThis is an updated post of the original here. Whether you’re new to the frontend at RIMdev or looking for more about our Frontend team...
Team RIMdev FrontendIf you’ve ever worked in Azure Data Studio, you may find tab colors very useful. They allow you to visually separate different connectio...
Documentation Azure Data StudioIf you’re not familiar with Platform UI, it’s a utility rich CSS framework we created. As we look to migrate all of our apps and static ...
UI UX CSS SassGet ready to celebrate because, as of Friday, September 18, 2020, Evan You, creator of Vue.js, announced Vue 3 is officially released. He...
vue3 frontend developmentTypically with ASP.NET Core 3.1 when no specific authorization requirements are set all endpoints are publicly accessible. When you’re wo...
asp.net coreIf you have used slots in Vue, you know that it provides a clean way to vary content that is displayed in child components. For example, ...
VueJS Slots Scoped Slots JavaScriptEver been confused about naming a branch with Git? Looking for a good naming convention? Well, I might have an answer for you. I’m not saying it’s the answer but it hasn’t let me down yet.
I’m that dev who never deletes local branches. Maybe that’s my problem right there. I guess I’m a bit of a branch hoarder. You never know, I might need that branch again. Anyways, the convention I came up with was to name my branches after the GitHub issue number I was working on, with my initials as a prefix. The initials help, I think, with visibility within our team. So, a branch name could be as simple as this: tk-7785.
This branch naming convention has a couple of benefits when it comes to using GitHub. First, it ties the branch directly to the specific issue I’m working on. When bugs come up during the QA process and I’ve moved on to another issue, I know exactly the branch I need to reference when making the fix. I don’t need to look for something ambiguous like responsive-nav-updates. I’ve used names like that for my branches in the past, but when you don’t delete them regularly you forget which responsive-whatever-changes you did the work in. Sure you could look back through the history in the GitHub issue, but I’ve found that it’s a heck of a lot quicker to just look at the issue number, and boom, I’m there.
The second benefit I’ve found is connecting the issue with the corresponding pull request (PR). I like to add the issue to the PR description. You can do this pretty quickly in GitHub. You just type #{issue-number}. So an example would be something like: Issue: #7768. If you forgot the issue number, you’ll see it in your branch name above the comment section.
If you’re using an app like ZenHub, as RIMdev uses, then you can also connect the issue using their tool. Again, you connect the issue by the issue number. You can search for the number or the issue name but you already know the number… remember?
This naming convention is probably best for smaller issues. But the key I think is to include the issue number. Say you’re working on an Epic with your team. Well, that Epic has an issue, so you could still create a branch to push to your upstream for others to use. In that case, I might do something like header-redesign-{epic#}. From here, your team could still create feature branches locally with the subsequent issue numbers, then PR to the Epic upstream.
Naming things can be difficult. Finding things with terrible names can be more difficult. In trying to keep it simple, I came up with this method and it helps me keep track of my PRs and issues. I don’t need to put too much thought into it. I know my initials and I know the issue number.
I hope this helps anyone who might be confused when it comes to naming branches. Let us know in the comments if you have a method you like.
