3 ms·

> > It's easy enough to include a bug number in commit messages to tie the two together. > No. This is absolutely not enough. Does the commit resolve the issue

> > It's easy enough to include a bug number in commit messages to tie the two together. > No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature? They just said that the bug number was enough to "to tie the two together". They didn't claim that was all that the commit message can or should say. For example, "added tests for #24" (followed by some details) would follow that template. > Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version control is the protocol for sharing information, especially useful because it's understood by the "grunts" actually creating the product. If a manger doesn't understand this language he or she will be as useless as a manager who doesn't speak any natural language his or her team speaks. This is ludicrous. The point of version control is to understand the way that the source code changes. Managers do not need to understand the software at that level of granularity, that is our job as software developers. Issue trackers are a much better fit for that.

crabbone 1y ago
> They just said that the bug number was enough to "to tie the two together". What's the other one they are tying together? Presumably the first one is the commit... > This is ludicrous. The point of version control is to understand the way that the source code changes. No it's not. This is why version control exists in programs that generally don't deal with code, s.a. Microsoft Word for example.
- Joker_vD 1y ago
  And the other is the bug, whose number is being include in the commit message. So the commit is tied to the bug it addresses (whatever "addresses" may mean) by including the ID of that bug in the commit message. Also, just to clarify, you can have several commits that refer to the same bug, and also commit message may (and likely should) contain some other text in addition to the bug number.
  - crabbone 1y ago
    But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless. To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code: * QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer). Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support... All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release. If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version... In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.
john_the_writer 1y ago
I'd go a step further. Sometimes as a dev, there's no need to even understand the whole app. A Front-end dev doesn't need to know how the API level works and the API dev's don't need to know how the Dev-opts work. I mean it's not a NEED.. All the FE dev need to know is that the API returns the data. Extended.. all a dev of one microservice need to know is that micro-service-x returns..

crabbone 1y ago

> They just said that the bug number was enough to "to tie the two together". What's the other one they are tying together? Presumably the first one is the commit... > This is ludicrous. The point of version control is to understand the way that the source code changes. No it's not. This is why version control exists in programs that generally don't deal with code, s.a. Microsoft Word for example.

Joker_vD 1y ago
And the other is the bug, whose number is being include in the commit message. So the commit is tied to the bug it addresses (whatever "addresses" may mean) by including the ID of that bug in the commit message. Also, just to clarify, you can have several commits that refer to the same bug, and also commit message may (and likely should) contain some other text in addition to the bug number.
- crabbone 1y ago
  But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless. To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code: * QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer). Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support... All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release. If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version... In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.

john_the_writer 1y ago

I'd go a step further. Sometimes as a dev, there's no need to even understand the whole app. A Front-end dev doesn't need to know how the API level works and the API dev's don't need to know how the Dev-opts work. I mean it's not a NEED.. All the FE dev need to know is that the API returns the data. Extended.. all a dev of one microservice need to know is that micro-service-x returns..