4 ms·

Any tips for someone outside the industry wanting to up their hobby programming game? Basically just trying to avoid the Useful_Script_v2-Final-Final-ReallyFina

Any tips for someone outside the industry wanting to up their hobby programming game? Basically just trying to avoid the Useful_Script_v2-Final-Final-ReallyFinalThisTime.py syndrome, and realizing the value of a dated change history.

CitrusFruits 3y ago
I think you can immediately get value out of Git, even if you don't understand almost anything. Also there's a lot less footguns if you're not collaborating with anyone else.
entropie 3y ago
You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.
- sorenjan 3y ago
  That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
  - dolni 3y ago
    > What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes. Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will). Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.
    - sorenjan 3y ago
      I've seen so many people do the "select function body, copy, toggle comment, paste copy of function, try out ideas on this new version" workflow. I've done it plenty too in Matlab and similar during various labs at school. I'm not talking about best practice during software engineering, I'm talking about having the confidence your code can easily get back to a known good state if you want to experiment, like beginners should do a lot of. And plenty of times functions are self contained enough that you can change the function body without changing other code as well.
- dolni 3y ago
  Telling someone to "delete your .git" is actually TERRIBLE advice. This should never be necessary unless you go screwing around in .git and break internals. It has a high probability of causing irreversible data loss. It's exactly the worst habit to build if you want to start collaborating. If your repo ends up in a weird state, learn how to fix it. It should not be terribly complicated, especially if there is no rebasing happening.
aquova 3y ago
The main complexities of git really come when you start having to work with other people also editing the same files you are. If you're just doing a solo project, you'll likely be mostly on a single branch, maybe a handful of others if you're experimenting a lot. In that case, you largely just need to know add, commit, push, checkout, and can largely ignore the complexities of merging and rebasing.
spondylosaurus 3y ago
Check out the book Learn Git in a Month of Lunches. It's exactly as advertised—only thing to keep in mind is that it was written before the master > main changeover, so depending on your local config you may need to swap that out when you're following along with its exercises.
thewebcount 3y ago
My suggestion would be to not learn git. Go with just about any other version control system if you’re not using it professionally. I’ve used cvs, Subversion (svn), Perforce (p4), and others. Honestly, Subversion and Perforce were both significantly easier to setup, learn, and use than git. While they all have their growing pains, it took me about a week to get used to Perforce. It took me more like a month or two to get used to svn. I’ve been using git for years and still find it very hard to use and strongly dislike interacting with it.
- badsectoracula 3y ago
  I second Subversion - though only because it is the closest to an open source alternative to Perforce. Otherwise it has a bunch of problems, like three separate half-baked implementations for shelving and aside from TortoiseSVN every other GUI front end has been either abandoned or on life support with a bunch of bugs. But unless you have to work with other people in places like github, etc, it beats having to bother with git - especially for games that have a ton of binary files (which, unlike what some people will tell you, you want to have both version controlled and in the same repository). Hell, if you really want a DVCS go with something like Fossil, it is still much easier than git, simpler to setup (just a single binary) and has more features (wiki, bug tracker, forum, etc) that you will find useful anyway. Though personally the best experience i had with VCS is with Perforce, at least in gamedev: check out the latest version, merge any local changes, make modifications in a changelist, shelve the changelist in case i want to stop working on something and work on something else, use the shelve to send a WiP version to a coworker to merge with his changes (or see if things work as expected) or for code review, etc. Sadly Perforce seems to be bound in a company that tries to sqeeze it for all its worth, adding a bunch of stuff of questionable usefulness, etc. It'd be nice if there was an open source alternative to it that allowed for the same or very similar workflows, all the issues i had with P4 over the years (e.g. merges between streams) were due to how P4 seems to be implemented, not due to anything inherent in the workflows themselves. There is no reason for an alternative to copy all the bugs.
- tasuki 3y ago
  Hard disagree. Subversion is awfully complex compared to git. Yes, Subversion is initially easier to learn and use than git. It's not easier to set up as it's client-server while git is fully local. Also Subversion is an incongruous mess.
jcparkyn 3y ago
The light bulb moment for me learning git, which I don't see get mentioned nearly enough, was this: Stop thinking in terms of branches, and start thinking only in terms of commits. Pretty much every git operation makes so much more sense when you consider your repo just as a tree of commits (technically a DAG), rather that trying to reason about what it does to the branches. Branches are really just pointers to commits which can change over time, and most git commands don't really care about them.

CitrusFruits 3y ago

I think you can immediately get value out of Git, even if you don't understand almost anything. Also there's a lot less footguns if you're not collaborating with anyone else.

entropie 3y ago

You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.

sorenjan 3y ago
That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
- dolni 3y ago
  > What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes. Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will). Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.
  - sorenjan 3y ago
    I've seen so many people do the "select function body, copy, toggle comment, paste copy of function, try out ideas on this new version" workflow. I've done it plenty too in Matlab and similar during various labs at school. I'm not talking about best practice during software engineering, I'm talking about having the confidence your code can easily get back to a known good state if you want to experiment, like beginners should do a lot of. And plenty of times functions are self contained enough that you can change the function body without changing other code as well.
dolni 3y ago
Telling someone to "delete your .git" is actually TERRIBLE advice. This should never be necessary unless you go screwing around in .git and break internals. It has a high probability of causing irreversible data loss. It's exactly the worst habit to build if you want to start collaborating. If your repo ends up in a weird state, learn how to fix it. It should not be terribly complicated, especially if there is no rebasing happening.

aquova 3y ago

The main complexities of git really come when you start having to work with other people also editing the same files you are. If you're just doing a solo project, you'll likely be mostly on a single branch, maybe a handful of others if you're experimenting a lot. In that case, you largely just need to know add, commit, push, checkout, and can largely ignore the complexities of merging and rebasing.

spondylosaurus 3y ago

Check out the book Learn Git in a Month of Lunches. It's exactly as advertised—only thing to keep in mind is that it was written before the master > main changeover, so depending on your local config you may need to swap that out when you're following along with its exercises.

thewebcount 3y ago

My suggestion would be to not learn git. Go with just about any other version control system if you’re not using it professionally. I’ve used cvs, Subversion (svn), Perforce (p4), and others. Honestly, Subversion and Perforce were both significantly easier to setup, learn, and use than git. While they all have their growing pains, it took me about a week to get used to Perforce. It took me more like a month or two to get used to svn. I’ve been using git for years and still find it very hard to use and strongly dislike interacting with it.

badsectoracula 3y ago
I second Subversion - though only because it is the closest to an open source alternative to Perforce. Otherwise it has a bunch of problems, like three separate half-baked implementations for shelving and aside from TortoiseSVN every other GUI front end has been either abandoned or on life support with a bunch of bugs. But unless you have to work with other people in places like github, etc, it beats having to bother with git - especially for games that have a ton of binary files (which, unlike what some people will tell you, you want to have both version controlled and in the same repository). Hell, if you really want a DVCS go with something like Fossil, it is still much easier than git, simpler to setup (just a single binary) and has more features (wiki, bug tracker, forum, etc) that you will find useful anyway. Though personally the best experience i had with VCS is with Perforce, at least in gamedev: check out the latest version, merge any local changes, make modifications in a changelist, shelve the changelist in case i want to stop working on something and work on something else, use the shelve to send a WiP version to a coworker to merge with his changes (or see if things work as expected) or for code review, etc. Sadly Perforce seems to be bound in a company that tries to sqeeze it for all its worth, adding a bunch of stuff of questionable usefulness, etc. It'd be nice if there was an open source alternative to it that allowed for the same or very similar workflows, all the issues i had with P4 over the years (e.g. merges between streams) were due to how P4 seems to be implemented, not due to anything inherent in the workflows themselves. There is no reason for an alternative to copy all the bugs.
tasuki 3y ago
Hard disagree. Subversion is awfully complex compared to git. Yes, Subversion is initially easier to learn and use than git. It's not easier to set up as it's client-server while git is fully local. Also Subversion is an incongruous mess.

jcparkyn 3y ago

The light bulb moment for me learning git, which I don't see get mentioned nearly enough, was this: Stop thinking in terms of branches, and start thinking only in terms of commits. Pretty much every git operation makes so much more sense when you consider your repo just as a tree of commits (technically a DAG), rather that trying to reason about what it does to the branches. Branches are really just pointers to commits which can change over time, and most git commands don't really care about them.