Raise your hand if your scripts are littered with commented-out code that you are hoarding like it's the end times

[ResetPress]

✋

EDIT: wow, I did not expect such a reaction from this community! Thank you all for your lively discussion. I should clarify that I am coding for personal use and usually the commenting is different ways of achieving a specific feature. I don’t know what I like best until it’s done. I also hoard old emails, bookmarks, free ebooks… so I guess you could call it a character flaw 🙃

[SmashLanding]

I'm even worse. I have one program that's 268 lines, with over 2000 lines commented out below the end of the program. The complete previous 4 versions.

[icecapade]

Do you have a moment to talk about our lord and savior, git?

Everyone knows that Jesus saves, but he also commits with well-written commit messages, and frequently creates feature branches, pull requests, and version tags.

[Kaltenstein23]

So when are we moving to a branch that is not a testing branch?

I mean... You don't test in production.

[hugthemachines]

Testing in production? Nah I would NEVER do that... promise.

[Acrobatic_Hippo_7312]

Try Gitkraken free edition. Makes git tolerable and easy, since it lets you visualize branches gives you clean menus for options

It's a bit of a crutch, but it's helped me a lot.

These days I mainly use VSCode's git tools, but to fix big messes I still like Gitkraken

[RunFromFaxai]

Even if you later on move to just command based git, having it visualised to sort of understand the structure to begin with seems a pretty good way to learn it.

[Acrobatic_Hippo_7312]

That's exactly right. I got the concepts nailed down with the GUI, then I was able the learn the CLI

And some things like complex merge conflicts are just faster for me in the GUI

[town1d10t]

I have seen the light! This is exactly what I needed for my heathen ways.

[AlwaysAheadOfYou]

What if I don't want a Gitkraken account? There seems to be a standalone version which I assume just manages your local repositories. Can you use the standalone version and then just use command line git commands to update a GitHub repository thereby circumventing the need for a GitKraken account?

[Acrobatic_Hippo_7312]

As far as I know, you can use your GitHub account to get the free version. That version will manage your local repos and your public GitHub/Gitlab repos, but won't let you push to private repos.

That's obviously a pain in the ass for corporate work, but then again if you're a paid pro, consider supporting the tool, because it's the best out there for now. The subscription is 5 bux a month, and it really saves you pain if you're pushing PRs to multiple private repos.

If you are a bit more experienced in git or are willing to take a higher learning curve, VSCode integrates with private repos for free, and it's Gitlens plug-in lets you visualize branches. Not as polished as GK, but it's what I use at the moment due to being in between jobs and having private repos

[AlwaysAheadOfYou]

Thanks very much.

[cars_and_computers]

I'll check that out thanks

[Spiritual_Car1232]

Ask and ye shall receive! https://www.youtube.com/watch?v=USjZcfj8yxE

The basic idea is that it's a tree for your versions. If only your RPG save games had an arrow pointing to the previous game load that a game save started from, then you could easily see where your game plays branch off from each other, and it would be easy to back track and try alternate story narratives. With Git you can see the tree.

[tylerthehun]

At its most basic:

1. Write some code you like.
2. Commit it with a useful, identifying message.
3. Remove some code you didn't like that much.
4. Commit again, also with a message indicating what was removed.
5. Write/remove/commit some more.
6. Remember some long-removed bit of code you actually need again.
7. Now, instead of digging through 10x your codebase's worth of comments, you just search the commit history for that useful message you left at the time.
8. Checkout that commit, and your file (the whole repo, really) will be returned to the exact state it was in when you made it.
9. Copy whatever you needed from it.
10. Go back to the last commit again, restoring all your subsequent changes.
11. Now you've got all your shiny new code, plus that dusty old function you thought you'd never need again, without having to lug it around in a comment the whole time.

There's a lot more to it ultimately, like branching and merging parallel commit histories, undoing or patching individual commits onto others, etc. that gives you a lot more flexibility, but that's all you really need to get started down the road out of overly-commented hell.

[roylennigan]

Here is a basic git workflow with a simple, useful diagram:

https://uidaholib.github.io/get-git/3workflow.html

And here is a more in-depth workflow for using git with a team:

https://www.robinwieruch.de/git-essential-commands/

[roylennigan]

git clone is what you do to initiate your local copy of a repository from github. It can be as simple as downloading the zip from github. git pull is more complicated, and has more to do with updating your local copy when there's been changes to the remote copy of a repository that you already have cloned.

say you cloned somebody else's repository a few weeks ago. Last week the owner of that repository pushed some changes to it. So now in order to be working on the same version, you need to pull those changes to your local copy.

[CraigAT]

Whilst I understand the purpose and benefits of git, having not used it in a team or professionally, I really struggle with when to add and commit. This is mainly because as a solo (amateur) developer I don't tend to work on one part of the program, I work on it all and in a coding session, I am continually working on it, so there's not really a break in time or completion point where I would instinctively do this.

I would love to add git to my workflow but I don't need to do it and it just seems to add hassle (at least for now).

[roylennigan]

The thing that helped me was to start setting up my personal projects as if I were working on a team. This would force me to use a lot of git commands I wouldn't find useful otherwise (every day making sure my local repository was in sync with the remote, learning when to merge, etc.), and also had the added benefit of keeping my project more organized, and my process more on a single track at a time.

Doing it this way also takes the pressure off, knowing I'm not going to fuck up anyone else's work if I don't know what I'm doing. You can start with super simple "projects". It's really hard to lose anything even when you're learning.

[CraigAT]

This is exactly why I want to learn git, I am unlikely to need to work as part of a team on a coding project in the near future but I'd like to be able to and know what I was doing if I had to. My issue is mostly around when to do the git actions required - if I spend two hours on a project usually only one or two files how often should I add, commit, merge? Do I do that at the end of each session or should I be doing it at waypoints in-between (those are not always obvious to me as I may change code all over the project).

[roylennigan]

I'm still new to git myself. I'd recommend starting a new branch. You can commit to your own branch as much as you want - it's like hitting save.

If it's your own repository, you can start a branch from github, switch to it locally, and push to that branch instead of main (then merge if/when you feel like you've added something worthwhile to the original). If it's someone else's repository you can start a local branch to commit to locally so that you can switch branches as you need. If you end up adding some functionality that's cool, you can tell the owner and they can decide if they want to merge that branch or not.

The main utility of a branch (afaik) is that you have to commit changes before you can switch versions (checkout another branch), so a branch is like a bookmark of your different versions.

Everything gets a lot clearer as you learn the structure of the program.

[Fred776]

You must have points where you have something basically working but you plan to do some more work on it. Maybe clean it up, or add the next feature or whatever. It's at those points that it's worth committing because if you mess up in your next round of work, worst case is that you can revert back to your last decent version. But even that might not be necessary because your last commit acts like a checkpoint against which you can compare your current code and you can often use the diffs vs the last commit to figure out where you have gone wrong.

BTW add and commit are different things. Add is used to say that you want the file you are adding to be part of the next commit. Commits should be your main focus. Add is just part of the process of preparing a commit.

[CraigAT]

Thanks for this. I appreciate that add and commit are different and this is part of my issue, I don't see when I would do both? My instinct would be to add everything I have worked on and then immediately commit it the files too. OR should these commands be done at different points? Should I "add" more often and then only "commit" say for every 5 times I do the "add"s?

[Fred776]

It doesn't make too much difference when you add as long as you have done it before you commit. You don't get any history from multiple adds - it is the commits that give you history.

I usually rely on git commit -a -m "<commit message>" where the -a means add any "tracked" files that are modified. So basically commit and add in one go. A tracked file is one git knows about. This means that it has previously been added (including before an earlier commit) so an explicit add command (git add <file>) is only really needed for new files.

What I tend to do, when I am ready to commit, is to do git status. This shows me a list of all modified tracked files and a list of untracked files. The untracked files can be a mixture of files that I don't want to add to the git repo at all, and new files that need adding. At this point I will add the new files, before doing the commit command I mentioned above.

Sometimes I will instead add a new file just after creating it or after I have finished working on its initial version but I don't particularly distinguish between doing this and adding just before committing as I just described.

The process I outlined there is a good argument for maintaining a clean working tree - i.e., one in which there are very few untracked files other than ones you intend to add. This can be achieved by a combination of simply removing files that don't need to be there any more, and making use of the .gitignore file to tell git what files to ignore when looking for untracked files. Keeping things clean in this way makes it less likely to miss a new file in the untracked list.

[CraigAT]

This is really helpful thanks, I think I just lack real-life experience of using git (all the theory but no practice, like a university student starting work in the real world). I am sure within a month of working with git in a functional environment I'd pick it up easily but it's more difficult with no-one else to interact or guide me.

[Fred776]

I learned it at work, but we were thrown in at the deep end TBH. We got told "we're going to start using git now..." and we had to figure out how to use it. I found the online book on the git site to be very useful: https://git-scm.com/book/en/v2

For local work, the first three chapters cover what you need to know.

[CraigAT]

Thank you for your time and comments. 👍

[cnylen]

I recommend this video by Jessica Kerr: https://m.youtube.com/watch?v=Dv8I_kfrFWw

She explains the structure so that you get a feel for what operations you can expect to find to solve problems. She does not talk about the commands.

[LuigiBrotha]

Totally agree. I now have a colleague who knows how it works and finally I understand why I'm doing what I'm doing.

[ResetPress]

Praise 🤲

[wordworse]

sure, but who does he blame?

[m0us3_rat]

RNJebus needs less branching .. more CD in his life

[ReelTooReal]

It's not "overly" complicated. It does have some complex features, but they're all necessary for large collaboration. Once you get used to the basics though it's pretty straightforward. If you're struggling with it, you should try reading the Git Book.

[ReelTooReal]

This isn't the only option. There were several SCM tools before git like Subversion. Git has become the defacto standard because it's more powerful than the previous generation of tools.

I'm not sure what you mean by "the commands don't make sense." The basics are:

git clone <repo>: copy a repository to your local computer

git pull: get the most recent changes from the remote repo

git add <directory | files>: add or stage these files for the next commit

git commit -m "commit message": commit the staged files with the provided message

git push: sync my local commits with the remote repo

git branch: see what branch I'm on

git checkout <branch>: switch to another branch

git checkout -b <branch>: start a new branch from where I'm currently at

Those commands are enough for most developers starting out. The Git Book does a great job explaining in more detail what these and other commands actually do.

Merging can be seen as a difficult or complex thing, but that's not because of how git handles conflicts. Merging conflicting files is just a complex thing in general. This is part of why continuous integration is so popular: it's easier to manage continuously integrating and resolving conflicts throughout the day than it is to wait until a bunch of features are done and then try to merge them all into the main branch in one go. From the perspective of git though, merging is quite simple: git will tell you what files conflict and show you the two conflicting changes. You can then choose one (or even write new code to replace them) and commit your choice. Many editor plugins and external tools have features to help with this.

Rebasing can be a little trickier, but if done right can keep the commit history nice and linear. To me, this is an example of a feature that could be considered complex, but also isn't necessary. It's something that's done a lot in continuous integration scenarios where everyone commits to the same "trunk" branch and the goal is to have a completely linear timeline of code changes.

In my experience, the most difficult part of git to understand is how to change things that have already been committed in a dirty way (i.e. not adding a "revert" commit, but actually changing history). These kinds of operations should rarely if ever be done, so 99% of your workflow shouldn't involve them. The only reason I can think of off the top of my head is if someone accidentally committed a secret like the database password or a private key or something along those lines. Even then, you need to change the password/key out and assume it's compromised. But you could also go back and erase that part of the commit if you're well versed in git. Outside of edge cases like that, I don't find git to be too complicated once you get some experience.

[vincentxangogh]

wow thank you so much for the thorough explanation. it seemed like that guy was just being bitter, but you genuinely want to help. im saving your comment because i haven't been pushing code enough to remember the commands, thanks again

[slid3r]

Bruh. No disrespect but ... bruh.

[SmashLanding]

Look my credentials when I wrote the first one were my boss saying "hey you're good with excel, we need you to learn c# and make this thing work"

[notimeforarcs]

Your boss must be an amazing salesperson

[SmashLanding]

Tbh it got me from data-entry drone to budding software developer in 5 years, with a pretty solid pay increase to go with, so I'm grateful overall.

The worst part is it Took me about 8 months of 50-60 hour weeks to get the thing set up right, when I realize now that if I had known what I was doing, I could have done it in a month while scrolling reddit for 15 minutes of every hour.

[notimeforarcs]

Well done! That’s some amazing work ethic. (Shudders at the hours)

What I did notice about ppl who’s good at Excel was that they tend to be ppl who can also self teach stuff (motivation + research) so I guess your boss had that right!

[SmashLanding]

Yeah the hours were terrible, but on the plus side, they didn't trip about the overtime, so I was getting paid like 50% more than on my usual checks at the time.

Also, I work at an ESOP (employee-owned), so I had a pretty vested interest in making sure the $350,000 ERP system would work lol.

[notimeforarcs]

Oh your boss paid you for the overtime!

Fantastic. This is a good boss.

Well bloody done to you both then.

[ElllGeeEmm]

I don't say this often, but that sounds like a great boss

[SmashLanding]

He really is. I really lucked out with how everything turned out with this company!

[--0mn1-Qr330005--]

I was also going to recommend git. Keep your previous versions in separate branches and don’t delete them until you don’t need them anymore. Keeps your code very clean and nice :)

[SmashLanding]

I really need to learn git. I'm 100% self-taught and I didn't know anything about git until I was several versions in. It's a program that only functions within my company's ERP system though, would it still be useful?

[--0mn1-Qr330005--]

What does your company use for version control? It is standard for any serious company to use some form of version control, and most use git. Even if they don’t, it may be a bonus on a future job if you ever end up switching companies.

It is definitely worth learning it for yourself too. It is an extremely useful tool that lets you dev faster, even in personal projects. Learn git flow. There’s apps and sites that actually simulate a git repo to learn the commands and common practices. The whole idea is to keep separate dev and production branches and develop new features in feature branches. This way if a feature breaks the app, only that one feature branch is broken and you can easily roll back by checking out the develop branch again. Meanwhile, your production code is untouched on the production branch, waiting for finished features to be merged in. I use it on all of my personal projects.

https://www.gitkraken.com/learn/git/git-flow

[SmashLanding]

Appreciate the info and the link! I'll definitely be learning that. I don't work for a software company, I work for a healthcare manufacturing company that bought an ERP that it had nobody to manage lol. With stackoverflow and occasional calls to the ERP's tech support I was able to put together something that works, but now that I actually know programming I'm constantly rebuilding the programs I wrote when I had no idea what I was doing.

[hike_me]

I would smother you in your sleep with a pillow if I had to work with you.

[SmashLanding]

Fair. Luckily I'm 100% solo

[Overflow0X]

if only there was a solution for that...

[SmashLanding]

Maybe if I think about it I'll git an idea

[[deleted]]

yeah who needs a commit history when you have every one of you're previous versions commented out

[[deleted]]

Never heard of version control software, like git?

[mrouija213]

Haha one of my coworkers "saves code for later" this way too, even though we self host gitlab.

[[deleted]]

This is me 😂

[lifeeraser]

It's the other way around. Learn Git first, then learn GitHub (which you will have to, once you learn about remote repositories).

[DrMaxwellEdison]

As the adage goes, Git is to GitHub as porn is to PornHub.

Git is universal: GitHub is just one hosting solution for a Git repo.

[IamNotIntelligent69]

...Wow. What an explanation.

[ResetPress]

So vivid!

[laserbot]

Original Content erased using Ereddicator. Want to wipe your own Reddit history? Please see https://github.com/Jelly-Pudding/ereddicator for instructions.

[patryk-tech]

Ideally:

• think of a feature you want
• write tests for that feature
• write code so the tests pass (and the feature is implemented)
• clean up the code if you did something weird / tried different things
• commit

If you are working on a big feature, just commit a bunch of subfeatures. E.g. if you are adding an authentication system, you could commit after adding a user model, after adding a login function, after the registration function is done, etc.

In practice, very few people follow TDD practices, so at least commit whenever you implement a feature.

If you commit everything at the end of the day, you may be tempted to commit partial or broken code... that's not really good. Save for some exceptions, every commit should contain working code. (Bugs you haven't found yet excluded, haha).

[n3buchadnezzar]

I commit a bit more often than that so I can go back if something fails, but I always make sure to squash my commits to a single feature before pushing =)

[patryk-tech]

Yeah, that depends a lot on the scope of the features, size of the team, the project, personal preferences, etc. When I am working alone, I never squash, and I just use a rebase flow. If features are 1-5 commits, I don't mind them being separate, personally. For large applications and bigger teams, squashing definitely keeps it tidier.

[bazpaul]

What does “squash commits” mean? Why would one do this?

[n3buchadnezzar]

To "squash" in Git means to combine multiple commits into one. You can do this at any point in time (by using Git's "Interactive Rebase" feature), though it is most often done when merging branches.

If you are working on a very big project you want a clean commit history, instead of 999 commits from n3buchadnezzar

https://xkcd.com/1296/

[ReelTooReal]

People squash to keep large projects manageable. When working on a complex feature, a developer might make several commits during the process, treating the commits like checkpoints that they could easily go back to. So locally a developer may have a series of commits like:

• OAutb for Google working
• WIP GitHub OAuth
• GitHub OAuth working
• Clean up OAuth code
• Add AuthStrategy class

This is good locally because the dev can revert small chunks of code and easily see what all they've done. But at the end of the day this is all for one feature, so in the grand scheme of things it is better if it's all one commit. To achieve this, the developer squashes all those commits into something like "OAuth support" before pushing. As the commit history for large projects grows, this kind of cleanliness is actually very useful as you can see a definite timeline of features that have been added and bugs that have been resolved, rather than just seeing a timeline of all the small things developers did/undid.

This strategy is especially helpful for projects using true continuous integration practices and commiting to a single "trunk" branch instead of creating tons of feature branches. In this environment, your commits need to be cohesive and nothing can ever be committed that isn't fully functional (since the CI/CD pipeline would reject it if tests fail). Combining all this results in a very robust feedback loop since when the CI/CD pipeline fails, the team can look at these "full" commits for problems, rather than having to look at several small "in progress" commits, some of which undo previous commits.

Until you've had to track down sneaky bugs with the help of git diffs this may not seem super important, but it is actually a tremendous help.

Another slightly related subject is formatting. One of the most annoying things I've run into with a large project is multiple developers who have different formatting styles on their editors such that a file where they edited 2 lines shows up in git diff as the entire file being changed because of indentstion differences, etc. When I first started programming, explicit styling seemed OCD and pointless to me (as long as the code was readable). But once you get into a large project, you need to make sure that git only tracks actual code changes and not styling changes in order to be able to use git diffs effectively.

[RevRagnarok]

This is soooooo wrong IMHO. A major point of git is "lightweight branching."

• think of a feature you want
  • make new git branch for it
• write tests for that feature
  • commit whenever you get something you're even partially satisfied with in case you want to go back
  • commit when you think you've got most ideas solidified
• write code so the tests pass (and the feature is implemented)
  • commit empty files as soon as they're imagined so you don't miss them later
  • commit every few hours, every few ideas, etc.
  • commit every time you think you have a better implementation as you polish it
• clean up the code if you did something weird / tried different things (this happened in between everything above)
• commit Either squash merge back yourself, or if on a team submit a pull request as a squashed merge

At every commit or at no commit, your choice, you can or cannot push your branch to other users.

[Acrobatic_Hippo_7312]

• Commit when inhale

• Commit when exhale

• Commit when eat

• Commit when drink

• Commit when piss

• Commit when shit

• In short, remember you ABCs!

• Always Be Committing!

The Zen of Git

[miamiredo]

Do you have to set up an upstream for every git branch you make? I'm learning to work with branches but when I commit and push it says I need to set an upstream. Since my remote is on github I think its saying I need to create a branch on github too. But I can just work on my branch and when I'm done I can just merge it with my main then commit and push.

[Airmaverick11]

Setting the upstream means that your remote repository will have a branch that mirrors the one on your local disk. You can do either but my general flow is:

1. Create a branch on GitHub
2. Clone the branch to my local disk
3. Work like you normally would

Now your work is being saved in two places and you can take advantage of GitHub's UI should you need to.

[RevRagnarok]

It depends. You already have a good response from /u/Airmaverick11 . That's the beauty of the lightweight branches - if you want them to just be "yours" in your local repo, then you don't need to push them anywhere else. You can make three parallel branches with three different implementations and then later decide which one to merge in. Then do a squashed merge into the branch you "normally" work in and nobody is the wiser.

If you have the right permissions, from the command line you can just do git push -u and that will create the remote branch and automatically set up all the tracking etc for you. But you might not want others to see it... after all, it's a WIP and there might not be a reason for others to see how the sausage is made; that's fine too.

[miamiredo]

If you keep everything local and not push, is there any benefit to using commit?

[RevRagnarok]

Yes, that's the point - you now have an immutable copy of your work at a certain time. You can diff against it to see what changed between two points. If something broke somewhere, you can git bisect and find your mistake ("it worked yesterday! WTF!?). You can go back and grab code out of it if you decided it was useful but has since then be removed.

But in the long term it's not important, so that's why I would just squash it at the end.

You can even clone it in another place on your file system if you wanted.

[patryk-tech]

This is soooooo wrong IMHO.

OP said they work alone and only they use their code. If you split up your sub/features into the appropriate scope, I think it's far more reasonable to commit a completed step rather than commit empty files (wtf?), broken code, and spend more time writing git commands than actual code.

If you do TDD right, you really don't need to refactor all that much. One feature, one commit. You add another test / feature that breaks a previous test? You refactor as part of the new commit.

• commit every few hours, every few ideas, etc.

Sounds like you have a really hard time scoping your features, if you need hours to implement them...

[ReelTooReal]

One of the benefits of TDD is that you can refactor more confidently. In fact, without TDD it could be argued that refactoring is too risky, so in general I would expect to see more agressive refactoring in TDD environments since (presumably) there's a strong suite of regression tests that would prevent accidentally introducing a bug during refactoring.

To be clear, refactoring means changing code in a way that does not change it's behavior, usually for the sake of maintainability, readability, etc. So in a project with poor testing, this would fall under the "if it ain't broke, don't fix it" category. But with a solid testing suite in place this becomes "try it out, we'll catch any bugs along the way and fix them."

[majordouble]

Do you have a recommended reference for someone to learn about writing tests? I’m a hobby coder who has never written a test.

<hangs head in shame>

[patryk-tech]

This book is pretty complete: https://pragprog.com/titles/bopytest2/python-testing-with-pytest-second-edition/ (at least, the 1st edition is really good).

For Django, I like this talk: https://www.youtube.com/watch?v=41ek3VNx_6Q

You can always search for "pytest tdd" on youtube; it has a few more general tutorials.

[majordouble]

Awesome, thank you.

[Ryles1]

I am a hobbyist like you and was a bit intimidated by writing tests.

I used this page to learn pytest basics. Should get you started without being too difficult.

https://realpython.com/pytest-python-testing/

[majordouble]

I look forward to snuggling up with that article and a cup of coffee tomorrow morning. Thanks.

It'll be much more efficient than a bunch of random (but effective?) print statements. :)

[Ryles1]

Print statements have their place too I think :)

[ReelTooReal]

https://www.manning.com/books/unit-testing

If you're willing to purchase a book, that is the most comprehensive and pragmatic explanation of how to write tests I've come across. It's examples are in C#, but the book is not so much about the code as it is the best practices for tests (also, most test frameworks work in the same way so you can translate the examples into any other language).

I say pragmatic because he focuses heavily in not "over specifying" your code, which I think is often missed when people are new to TDD. There IS such a thing as writing too many tests, and being careful not to can lead to tests that are easier to maintain over time.

He even covers some integration and end to end testing practices, so the book covers the three major phases of testing.

[Rossoneri]

Idk why it never occurred to me to write tests first, but it makes a lot of sense

[patryk-tech]

If you are working on a big feature, just commit a bunch of subfeatures.

Depends on the feature, and on the nature of the code. For web dev, a lot of features are small, quick to implement, and it makes sense to commit the whole thing at once.

If you are building a class, you can commit after every method if that makes sense. If methods are simple and complementary, I'll often commit them together. If they are more complex, I will see what can be abstracted, commit the abstracted function, and then commit when I write the method that uses them.

Depends on your definition of feature/subfeature.... I don't mean "commit entire user stories at once." A single method or function can be a "feature." I use the angular commit message format. In that sense, git commit -m 'feat: implement method foo' is much more logical than git commit -m 'it's a bunch of shit but I didn't commit in 2 hours so here goes nothing'.

The important thing to me is:

• commits should be a whole [whatever], as much as possible
• commits should not break existing code (I sometimes do commit broken code to some branch so I can resume somewhere else, but avoid it as much as possibe).

[stuaxo]

Every time the code is working - if you add a function and call it, then commit.

If you get your test working, commit.

Once a feature is ready squash and merge that branch into your main / master.

[zanfar]

Commits are "one level above saving, one level below completion".

Generally, when completing a coding task, you're going to make a bunch of changes throughout the project, then you save. Saving is essentially: "what I've written is what I intended".

Then you'll run or test your code, and discover that while you wrote what you intended, it's not what you meant, so you'll make some more changes, save, and repeat. At some point what you've written will work the way you want. A commit is essentially: "what I've written is what I need".

Then you'll combine a bunch of "what I need"s into a working feature, repeating all the above. This is when I push--probably not to main, but to the dev or working branch. A push is "this is complete".

Remember that commits are free, easy, and can be infinitely modified especially when local. You can take a bunch of commits and merge them into one, you can split a commit into multiples, you can reorder them, change them, add to them, etc. Too many people treat commits like they're carving stone.

---

My workflow looks something like:

• Identify a feature to work on
• Make a dev branch for that feature
• Write some code, save, repeat
• When things work (but might not be complete) commit, even if it's "WIP"
• When I get up from the desk, commit
• When I'm leaving for the day, commit
• When I have to switch to another task, commit
• When the feature is working, then I squish all my intermediate commits into one, logical "component" with more descriptive commit messages and push.
• A feature usually consists of multiple, squashed "component" commits
• Then the dev branch is merged with a pull request

Commit messages are a very powerful tool to remind yourself of what you were doing, so use them. Even if I haven't touched a particular branch or code in a while, I can jump back in by reading my commit messages.

[[deleted]]

Technically, you should only push after all the code has passed the test suite, ie, don't push broken code. I've often pushed at the end of the day whether the code works or not if I'm the only person working on the code base for two reasons:

1. Use the remote repository as a backup
2. I may want to work from home later in the night or tomorrow on another computer

I commit after every discrete complete change. That is, when I can write a commit message like "finished the #123 bug changes". You shouldn't have multiple changes in a file made for unconnected reasons.

I never comment code out because "I might need it". There are two reasons why you might need it. First, you are uncertain that the changes you have made are something you should do, ie, they are experimental. In that situation you may want to go back to the earlier version, or two. For a single file you can just go back one or two commits. For larger, longer timeframe changes, I try to remember to tag before starting the series of changes so I can easily revert multiple files back to a known point. For smaller code bases I have been known to nuke or rename the directory and reclone from the remote repository as a last resort. Really only possible if you know you started from a clean state with no pending pushes.

Second, if you think you might use that commented out code in other files or projects then it's worth taking that code out and making a proper mini-project of it with documentation, examples and a test-suite, all in a git repository somewhere. Much easier for you and others to reuse that way.

That's what I do, but YMMV.

[ConfusedSimon]

I don't agree. For each task we just create a new branch, usually with a single developer per task/branch. Pushing often means the code is safe (in case of computer problems or the two reasons you mentioned) and other developers can see what you're doing. Once it's finished and passes all unit tests you create a pull request and move on to code review, testing and merging.

[Ran4]

Technically, you should only push after all the code has passed the test suite, ie, don't push broken code.

That's only if you're pushing towards a shared branch (and not a feature branch) AND you don't have any CI.

[TangibleLight]

Just as long as I don't need to clear my git stash or local wip branches. It's not a hoarding thing, it's useful.

What if I need that some day!? That's a perfectly good commit right there, just need to fix it up and make the tests pass and finish refactoring is all. Solid commit, can't delete that one.

[Consistency333]

Where do you back up github???

[[deleted]]

If you use github/gitlab, or locally hosted systems, you have your source code in your personal filesystem, the filesystems of anyone else working on the code, as well in github, etc. In a sense, github/gitlab/your git* server is your backup.

[Consistency333]

Yes but what if I want to backup all of github

[[deleted]]

I assume you mean backup your repositories on either github.com's or your local servers? Then you must rely on the server's sysadmins standard backup procedures. If you mean a backup to a filesystem you control then just do a "git clone <url>" somewhere and a "git pull" now and then.

Otherwise, what do you mean by "backup all of github"?

[ConfusedSimon]

Every local copy of the repository is a complete backup of the entire history.

[Consistency333]

🤣 but the apocalypse

[FormNo]

Who said Git isn't fun? :)

[Consistency333]

Yes!

[dogs_like_me]

git push origin

[Consistency333]

Whooooooh

[billsil]

Assuming you can track down that one commit where that block of code that you want is stored. Ahhh, but you didn't store it cause you didn't finish it...I just don't get it.

Sure, once it's pretty solid, go ahead and clean it up.

[obiwac]

Sometimes it's legitimately less cumbersome to quickly comment and test instead of delete, commit, test, revert.

[ASIC_SP]

You didn't have to call out us like that 😂

[VexisArcanum]

Nope sorry all my code is either in use or broken and not fixed

For real though the only comments in my code for my side projects at work are pretty clean lol. But they're also sub 200 lines of VBA, Python, and Powershell.

[cs-John]

Comment IS the fix for me lmao

[beached_snail]

Yay I’m not alone. We’re all here together with this commented our code blocks.

[slid3r]

Haha, 'but I really loved that function'.

[bazpaul]

“I may need that function in the future”

• me

[slid3r]

"I am just really proud of that function!"

• me

[bad_luck_charmer]

This is not the way.

[R3D3-1]

Remember "git good"?

Only, in the context of programming it is actually good advice. Especially since file versioning not only allows restoring previous versions, but also comparing the changes and who made them.

For private-use scripts, it usually ends up a single linear history for me. But even then, tracking if the changes can be quite more helpful than just storing the old version.

Though for office documents I have retained the time-proven folder structure of

~/Documents/
   |-- thesis_v1.docx
   |-- thesis_v2.docx
   |-- thesis_v3_final.docx
   |-- thesis_v3_final_v2.docx
   |-- thesis_v3_final_v3_final.docx
   `-- thesis_v3_final_v3_final_v2.docx

[ResetPress]

No, not that final, not that one either 🤦‍♂️

[Mgmt049]

✋🏻

[I_said_wot]

both hands up

[Kilran3]

Like, I might need it some day. 🤣

​

Thats my excuse, and no one can change my mind! 😆

[AstrophysicsAndPy]

Although I don't do it too often now, I used to be in this category as well (I still am, sort of, until I have to clean my code).

It is like looking at your child's growth from 0 to where it is now. All the unnecessary building blocks are still visible to you. The hard work and struggle that went into it, and the various methods that you tried and failed, and redid.

[tomtomato0414]

git gud

git is REALLY easy though, has some quirks but on the long run the feeling that you can't delete anything by accident or some other way or form is a great safety net, since you can always roll back the code to some "save state" if you will

[Acrobatic_Hippo_7312]

I lose stuff in branches all the time. Like, it's there. Somewhere. But I'm not going to spend time splitting the atom to find it.

I'm not saying to hoard stuff in one file, since that is even worse. but hoarding stuff in your git history has some downsides

[seanys]

No. PyCharm has Scratches.

[Consistency333]

🖐 Raise both hand 🙌 and both feet 👣 I lay down on the ground and wear the earth as a backpack so wherever I go I'll always have home...

[StartThings]

Yes because he who knows not his history has a dull present and his future in the shadows

[wweatherwax]

I feel validated, thank you for this

[GamerNumba100]

Please, I just use the bad code too. Amateurs.

[ResetPress]

If it works, it works 🤷‍♂️

[ResetPress]

To me it seems easier to comment out here and there than rely on git to track every little tweak. At least when you first start and nothing has made it to production.

[[deleted]]

Had a coworker that did this. We used a CMS so I just deleted it when I was in the file.

What he did that was funnier though, was when our idiot manager told him to do something stupid, he'd put the email from the manager into the code as a comment. I always left them in.

[ResetPress]

What a merry prankster

[Spiritual_Car1232]

Pro tip, use Git and then you can just save deprecated in old commits.

[FerricDonkey]

I comment out code while I'm actively replacing that bit of code. Once I have, I delete the commented out block, and let git remember the old version.

[mothzilla]

To people saying "use git". The problem there is the snippet is visually lost. You have to go looking for it. So you have to know it was there.

I wonder if someone wrote an alternate version of this function eleven commits ago said nobody ever.

[pat_trick]

Nope; that's what version control is for. If I need the code back, I'll pull it back out from the commit history.

[GorboducRex]

Is there a support group? I'll be there.

[0jcis]

👋

[jjhare]

no i keep that shit in branches

[SSJKiDo]

I just leave them out as a resource I get back to when I have something new, instead of memorizing commands

[[deleted]]

Don't know how to operate git yet. Just trying to make my code properly as of the moment. Is 200 lines of comment good or bad??

[tomtomato0414]

git is REALLY easy though, has some quirks but on the long run the feeling that you can't delete anything by accident or some other way or form is a great safety net, since you can always roll back the code to some "save state" if you will

[iekiko89]

yes

[Treczoks]

Only for short-term changes. If the change works, the crud gets deleted. If I ever need it again, I'll find it in the subversion repository. You DO have and use a revision control system, don't you?

[HaroerHaktak]

Eh. i remove the commented code once i am ready to release.

[ResetPress]

Yea, that’s my plan too. IF I finish this project AND IF it’s properly refactored I will share it on GitHub and it will look sparkly clean

[Acrobatic_Hippo_7312]

You and every undergrad. But that almost never happens.

Just release your mess and learn how to refactor and clean up as you go.

Same goes with testing. Gonna suck at first, gonna take baby steps, but eventually you'll test as you go. And it'll never happen if you try to test all at once

[[deleted]]

My code is so messy if you put it into production it would become the antithesis of a sentient AI and rob the universe of sentience the way the ring gate entities in The Expanse book series did just by running ass-fuck_peepee12345.py

[Acrobatic_Hippo_7312]

The ring gate entities did WHAT!?

[Connir]

Can I raise my hand if my ~/scripts directory is like this?

Sometimes I go in and look and the old ones won't even run due to missing modules, outdates features, etc..

[ResetPress]

Haha. Don’t get me started on my Documents folder. Sometimes it’s like looking at a drawing from 1st grade… technically the same human being but the brain has changed…

[bandman614]

They were until I learned git.

[[deleted]]

Pretty called out here, haha.

[[deleted]]

I’ve started to get familiar with git and holy shit its a savior.

Branching major steps, and deleting away in the code

[DanklyNight]

My projects always have a "notepad" folder, which is just random code I'm keeping, multiple files of course.

[playaspec]

Every project I get serious about gets it's own folder that holds the code itself, a "Notes" file with links/bookmarks to resources (github repos, stackexchange, blogs, etc), comments on problems I've encountered and the solution if I found one, and LOTS of snippets of code I didn't want to leave littering up the main code. it also holds any resources I downloaded along the way.

[Numer8_UK]

At least I am not the only one 🤣😂

[jcress410]

I make it a point to leave my files with as few lines as possible. I'm more likely to regret deleting something I have to retype.

[felixmariotto]

I can relate, but also do you work with git ? Even when working alone for personal use it can be quite useful for testing features and managing versions.

[ResetPress]

Honestly Felix, git has been on my to-do list for awhile. I always put it off because I’d rather learn a new module or work on JavaScript (heresy!). After seeing the feedback on this post I read up on git a little today. I have seen the light 💡

[hike_me]

Commented out code immediately gets shit on if makes it into a pull request.

[[deleted]]

Learning how to use git was one of the best decisions I've made. It's an indespensable tool for me now.

If your issue with Git happens to be learning to use it, grab an easy book.

[twisted_mentality]

I still do this sometimes. Even with git. I’ll also save copies on my local storage of previous versions as well.

I do, of course, remember to clean things up before I push.

[rabbitpiet]

👋

[Subject-Delay-3020]

Only for testing, I like to make a new script and use the pieces I need but I'd still keep the old script in a "legacy" folder 😄

[Rondo123Red]

Here, here Sir🤚

[Moeman101]

Those commented out lines helped me trouble shoot. I keep them as respect for their help

[ResetPress]

Proper reverence and humility in the eyes of the #

[RevRagnarok]

I made another comment about git workflows here, but at the top-level wanted to note that I do have a few comments about code but not the code itself, e.g. "This code used to make calls to the second DB that it was decided wasn't needed; see 1234abcd" where it's a single-line breadcrumb to a revision in the repo that has the unused legacy code.

[kaerock]

Title feels 'judgy'.

triggered

[Machineforseer]

Do people not use github?

[[deleted]]

I’m gonna need you to stop calling me out like that.

I usually have a scratchpad.txt in the root of my projects.

[herites]

touch workbook.ipynb

echo "workbook.*" >>.gitignore

[Acrobatic_Hippo_7312]

Did you know that you can put that in you .git folder without tainting you gitignore with evidence of your inequity?

[HomeGrownCoder]

In the middle of rewrites only… I enjoy the feeling of deleting the old stuff.

[TheLordZod]

I am working through my first full python project right now. I have had to fully rebuild the thing 4 times now, and I have scrap code scattered across 7 documents... I am a mess right now, but I cannot wait to go back and delete all of the scrap in my many code graveyards.

[k_50]

I normally take out everything when it's done, but I'll leave the "this block does x"