We 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 JavaScriptWe’ve been using Swagger via Swashbuckle for some time with our ASP.NET Full Framework applications. As we’re moving toward ASP.NET Core ...
asp.net coreWe’ve spotted some strange behavior before with ASP.NET Core and JSON serialization/deserialization, and I eventually made it back to try...
asp.net coreWe’ve spotted some strange behavior before with ASP.NET Core and JSON serialization/deserialization, and I eventually made it back to try...
asp.net coreAs we create CSS components in our internal framework, we typically try to use little if no JS. Our tooltips should be no different. We...
UI/UX frontend CSS Responsive DesignImagine you’re using Elasticsearch with your strongly typed C# models and nameof(MyProperty) and wondering why it doesn’t work. Turns out...
.NETI have been working as a software developer for almost three years, the most common exception or bug I made is NullReferenceException -Sy...
.NET C#Testing is an important step we can take as developers to reduce bugs in our code, but testing seems to be one of the best practices that...
Vue.js Jest TestingLast week I attended the annual user experience conference Convey UX in Seattle, where 50 UX leaders from all over the world shared their...
UI/UX frontend conference conveyux2020 conveyuxWe run a number of web applications at Ritter Insurance Marketing. Our primary datastore for these applications is MSSQL / SQL Azure. Our...
SQLWe’ve been working through upgrading our core applications from ASP.NET full framework to ASP.NET Core. Over the years we’ve assembled an...
.NETEver 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.
