Tags
.NET (42), Meetups (37), dotnetoxford (33), Git (12), Productivity (12), Career (10), LINQPad (8), PublicSpeaking (7), YearInReview (6), Docker (6), CLI (5), Testing (5), Software (4), Workflowy (4), Azure (4), BestPractices (4), Blog (4), Cake (3), Kubernetes (3), Vi (3), Snippets (3), Resharper (2), Podcasts (2), Zoom (2), Xamarin (2), Learning (2), NGINX (2), Evernote (2), Health (2), Debugging (2), DesignPatterns (2), Conference (2), CosmosDB (1), C# (1), Books (1), C# (1), AzureDevOps (1), AzureOxford (1), Aphantasia (1), IoC (1), Hackathon (1), Fonts (1), Documentation (1), dotfiles (1), OGN (1), Microsoft (1), Mocking (1), MVP (1), Neo4j (1), Wyam (1), TimeTracking (1), Powershell (1), RemoteWork (1), Security (1), Serilog (1)Create a trail ...
Whilst most projects are quite different from one another, the project management tools used are usually very similar. For example, most projects (hopefully!) store the source code in some form of source control system, like Git. Also, most projects involve some form of bug tracking system - eg. JIRA, Mantis, Redmine, etc.
Quite often, there's a direct correlation between an item in the bug tracking system, and a change that is checked into source control. The bug tracking system normally contains a combination of features and bugs, and may be used from the very beginning of the project.
Given this correlation, it makes sense to reference one from the other for future reference. A ticket in the bug tracking system always contains a description and comments; and source control always involves commit messages describing each atomic change that is made.
Having worked in the past for companies that enforce strict standards around commit messages, it feels natural and automatic for me to reference a ticket number inside a commit message, and vice versa. And depending on your chosen source control and ticket management system, you may well have tooling to help you with this, providing hyperlinks, etc.
Unfortunately, I do quite often see commit messages that are directly related to a particular ticket, but with absolutely no reference to which one. This makes it REALLY hard to track down exactly what change was made for a particular issue. Especially when the commit messages are also really obscure - eg. Fixed bug in order management system. This would have been just as easy to write [#1234] Fixed bug due to misspelt property in model. That way the commit message gives a brief summary, but you can quickly reference the ticket for more details. I normally would also include the commit ID in the closing comment of the ticket tracking system, so there's a two-way reference.
I know it's tempting to skip this kind of thing when you're in a rush, but it really does take seconds, and can save quite a bit of time if you need to back reference that change in the future.