Issues on GitHub — tutorial + a noobies point of view
To start with, I want to disclaim that I just filled my first issue on GitHub a couple weeks ago.
However, that’s the reason why I feel that’s good to have a post about this topic written by a noob such as myself, for an easy peasy tutorial with reasons on why you should add them to your daily coding routine.
the Reason Why I started using them
While I was creating my Shell Interpreter a couple of months ago, my course tutor suggested me to start using the Issues feature because of the project having so many files (at least at the time they were haha) and that would help organizing the work better.
the How To
It is not at all difficult to get the hand of this feature, however, there may be one thing or two that are not as instinctive as expected and you may find here.
The picture below shows what we see as soon as we click on a GitHub repository:
And more precisely, here’s the Issues feature:
Now I want to show you this next image:
This is how my newest repository looks like after clicking the Issues button. I filled 3 issues using the “documentation” label. You have more default label options such as bugs, enhancement, help wanted, or you can always customize them better for yourself.
If you look to the column on the right, you’re able to see that I assigned myself with these tasks. But, if you’re working with people on the same repository you sure can assign another collaborator with the task.
No more post its here and there, but everything detailed and truly organized
Personally, I find documentation to be of outmost importance, however, I’m not always in the best mood for writing my Read Me files, so in this way I can reorganize my priorities based on what I need to do urgently and what can wait a day or two.
Here’s the tittle of one of the issues, see the “#4" is in grey? This number is given automatically once you file each of your Issues, as you finish them this number is freed and can be assigned again.
Most importantly, this number is the one you need to use once you commit your changes!
When doing our classic git add sequence, remember to write in the commit you are using to complete the task after your important commit comment, the #<<number>> of the issue you want to close. Once you push, you can go double check your issue has been moved to the closed issues section.
Here’s an example of how it goes:
See how after I wrote in my commit “fix num from 0 to 2 in import — issue #1”? That’s how GitHub recognizes what you’re trying to do. And in the right bottom corner you can see it was commit 914fb67 which closed the issue.
Conclusion
While filling issues doesn’t seem as much fun, because you are giving yourself work, remember the work is already there to be done, why not document it and better your skills while completing your tasks?
There’s nothing as satisfactory as being able to see all the completed tasks you achieved yourself. You can go back at any given moment, also it can be of big help when encountered with a similar problem twice.
