But I understand when I don't I'm taking the risk that this will disappear with no recovery. Most of the time that's okay, some scripts have low reusablility and somethigs I need an excuse to refactor.
To run a business without it is inviting failure. Once you involve someone else the conditions to recreate get hazy.
It sounds like only one piece wasn't in version control. That might be why that developer is no longer there.
I religiously use version control, and additionally, I use PRs and issues even on projects I work on alone.
It's not about their purpose in itself, rather, it's about a structured process and discipline.
All in all, source control (and even PR/issues) virtually cost zero, so while there are arguments again unit testing/documentation etc., there's hardly an argument against it.
I could see being able to look at your code diff outside the context of your editor could help you identify issues you wouldn't otherwise see. Especially if your brain flips into code review mode when looking at a GitHub PR.
> Are you requesting a PR from yourself, approving the PR when you have meditated about it for a day? :)
He :-)
I definitely agree that this is more on the obsessive side of being structured - but on the other hand, the cost is virtually zero (I open and close PRs via commandline).
In those conditions, I'd say that issues and PRs are both complementary and necessary parts of a certain perspective/workflow. When I open an issue, it's a request for action. PRs are the other side of the coin - the represent the action that satisfies the request (as a matter of fact, "Closes #..." is crucial for me).
Opening an issue and closing it without a Pr, for me it... asymmetric (also practically: assigning a PR to an issues gives you the reference in the interface). Ultimately it's a matter of fully embracing a workflow.
Ideologies aside though, PRs nowadays are not just an isolated concept - typically, they carry various hooks (CI, code analyzers etc.) that do help. So, in a way, somebody is meditating on my code, even if it's just a machine ;-)
I do PRs for any minor/major features on a project that I work alone :) it helps to see a better diff in github, also see CI status (using drone) and also to review it after few days when I can be objective about it. Project is quite big at the moment with a lot of moving parts so it helps to have a process. Also, each PR has a name and short summary of what was changed, added, fixed. So when something breaks in 6 months it's easy to track down related PRs and refresh my memory.
But I understand when I don't I'm taking the risk that this will disappear with no recovery. Most of the time that's okay, some scripts have low reusablility and somethigs I need an excuse to refactor.
To run a business without it is inviting failure. Once you involve someone else the conditions to recreate get hazy.
It sounds like only one piece wasn't in version control. That might be why that developer is no longer there.