I appreciate this guide, so thank you, Gary.
My own special snowflake story: I am an experienced solo developer interested in getting up to speed with modern version control. I like that Git is popular and I prefer to learn well-supported tools. But every time I approach learning Git for my own needs, I get stymied and confused.
- I don't work in teams with other developers. I have no need to share code with anybody.
- I am not concerned about data loss, per se, because the systems I build include their own custom automated backup solutions.
- I don't develop in a VM on my local machine; I develop on a remote dev machine which is an exact system replica of the remote live machine (minus the software under development).
So what do I want from Git -- or something like it?
I want a good way to manage pushing features from dev to live with granular control. I may be working on 3 features plus a batch of bugfixes on the dev machine. When 1 feature and some of the bugfixes are ready to go I want to be able to push them live without pushing incomplete features live; and of course, I want this all to be as frictionless as possible because I don't want to waste time monkeying around with my dev tools when I should be working on dev itself.
Gary's guide doesn't completely get me here, but it is a nice, accessible start. So many Git resources I have read immediately launch into how Git works under the hood. Guess what? I don't care! Would you teach someone how to drive a car by first explaining how combustion engines work?
Maybe Git isn't the best tool for me after all, but with Gary's guide at least I know what commands to run without filling my head with an engineer's treatise of its internal engineering.
My own special snowflake story: I am an experienced solo developer interested in getting up to speed with modern version control. I like that Git is popular and I prefer to learn well-supported tools. But every time I approach learning Git for my own needs, I get stymied and confused.
- I don't work in teams with other developers. I have no need to share code with anybody.
- I am not concerned about data loss, per se, because the systems I build include their own custom automated backup solutions.
- I don't develop in a VM on my local machine; I develop on a remote dev machine which is an exact system replica of the remote live machine (minus the software under development).
So what do I want from Git -- or something like it?
I want a good way to manage pushing features from dev to live with granular control. I may be working on 3 features plus a batch of bugfixes on the dev machine. When 1 feature and some of the bugfixes are ready to go I want to be able to push them live without pushing incomplete features live; and of course, I want this all to be as frictionless as possible because I don't want to waste time monkeying around with my dev tools when I should be working on dev itself.
Gary's guide doesn't completely get me here, but it is a nice, accessible start. So many Git resources I have read immediately launch into how Git works under the hood. Guess what? I don't care! Would you teach someone how to drive a car by first explaining how combustion engines work?
Maybe Git isn't the best tool for me after all, but with Gary's guide at least I know what commands to run without filling my head with an engineer's treatise of its internal engineering.