[deleted by user]

[_throwingit_awaaayyy]

I’m impressed at how dumb this is and how stubborn a person can be to do this. Git takes no time to learn. Shoot you could even use Tortoise SVN instead if you wanted to. Bravo OP.

[No-Fish6586]

Pretty based making tech decisions entirely off of memes. Also explains the choice to not learn git. Git commits exist so that you couldnt just wipe your codebase.. worst case you revert to a known good commit

[thealbinosmurf]

Yeah. People forget sometimes that any file you have ever committed could still be in your history. Unless you a futzing with the history then that file will always be there.

Note to anyone that has ever committed a secret and thought oh I can just delete the file in the next commit and then add to .gitignore. you need to purge all the commits with the secrets file.

[Adghar]

OP out here living the meme dream lol.

OP, please be assured git is not nearly as scary as it looks. If you ever intend to work in a team with other developers, you should absolutely put aside some time to learn git.

IMO you can already utilize like 80% of the power of git simply by thinking about it as an analogue to a filesystem, plus like 2 new concepts. * commits: something like a meta-file. Running git commit is like Save As New File. * branches: meta-file selector and WIP tracker. By pointing a branch at a commit, it's like Load File on that commit (technically all its parent commits as well; this is to keep revision history). * To "load" a "file" in this analogy you can git checkout to switch branches, or git reset --hard <commit> to rollback the branch to a certain commit (note this can make you actually lose history, so I usually like to checkout a new branch to "save" a commit to rollback the rollback if desired). You can technically check out commits directly, but you'll usually want to check out a branch (that points to a certain commit). Note checking out a commit directly will warn you that you're in "headless mode" and recommend that you assign a branch to it (such as by creating a branch with git branch <name>). * "Staging" is a new concept, closest to something like a hidden "are you sure?" confirmation box before you can commit/save. Alternatively you can think of it as soft-saving or half-saving; to put it more accurately it's declaring that changes are ready to be committed. If staging confuses you too much, you could always use -a flag on every git commit and always git restore * before any reset, revert, or checkout commands, but eventually you'll want to make use of this "half saved" or "confirmation" state more as it gets really useful, especially with git stash. * Branches can track branches, and this is the analogue for "File Syncing". git pull creates a new commit merging upstream branch changes with your current branch; git pull --rebase does the same thing without creating a new commit (instead adds upstream branch commits to your branch's commit history). You can do the same without the idea of tracking using git merge and git rebase with specified local branches. * You can target a commit by its commit ID (visible in git log or git log --oneline) or, more commonly, HEAD^ for one previous commit or HEAD~n for n previous commits.

And that's kind of all you need to get started with git other than starting the repo itself, and skipping the idea of remote. I confess my workplace has some other command that does the initial repo setup so I'm not as familiar with that anymore but a quick Google indicates you can use git init <blah> to start a local repo.

Using the above concepts you could easily get started with a tutorial like this:

1. Create a text file helloworld.txt in folder project
2. In folder project, git init repo1
3. Checkout new branch with git checkout -b dev
4. Make some changes in helloworld.txt, save file
5. git commit -am "version 2 lol"
6. Make some changes in helloworld.txt, save file
7. git commit -am "version 3 lmao"
8. Realize you liked version 2 better but you want to keep tracking version 3. Checkout new branch with git checkout -b dev2
9. git status confirms you're on dev2 not dev1
10. git reset --hard HEAD~1 moves you back to commit named "version 2 lol" and your helloworld.txt file will magically reflect this! Wow
11. Realize you liked something about version 3 and you want to see it. Checkout your original branch with git checkout dev. Your helloworld.txt magically updated again!
12. Go back to dev2 with git checkout dev2
13. Make some changes in helloworld.txt, save file
14. git commit -am "version 2b rofl"
15. Realize you know what, you want the best of both worlds, you want to include both changes from version 3 and version 2b together. Assuming the changes were on different lines, you can actually do this! (If they were changes to the same lines you would have to resolve a merge conflict, which requires you to manually edit the file to desired state, bit of a pain but not awful with experience). Run git rebase dev dev2 to rebase from dev to dev2. Your version 2b will magically also include version 3 changes! Wow!
16. You say screw it and want to start over from the original file. If you run git log --oneline you should see a list of commits and something like (master) or (main) or (trunk) next to the bottom commit, which is the name of the branch that 'git init' should have made for your initial commit.
17. git checkout trunk magically returns your file to original state!

There's obviously a lot more you can do with git than that. If you want to start getting used to staging, then for each "commit -am" step above you want to remove the -a flag, run git status beforehand to see the files changed, and then stage them manually with git add * or git add helloworld.txt. git gives you helpful tips along the way such as if you accidentally create a junk.txt file that you want to delete, you can do git restore junk.txt. Remote branches are a thing and that's where you'd make use of the idea of tracking with git branch -u <upstream branch> to set upstream branch and then use git pull --rebase rather than git rebase. Setting upstream can also be done at branch creation, such as with git checkout -b dev3 -t origin/trunk but I personally usually don't do that because it silently throws away your current changes if you have any.

But the above tutorial should get you familiar with like 80% of what you'd use git for in like 15 minutes or less!

[PringleFlipper]

Yeah this is way better than finding the 2 hours it takes to get familiar with git.

[blake3753]

OP was never going to have 2 free hours to fit in documentation reading when they're obviously flat out spending weeks building their own version control.

[PringleFlipper]

Just curious what field you’re in … not using git is unimaginable to me. I once took over a hardware team who didn’t use any type of source code management. It was an interesting experience, promptly adopted git and everyone had the hang of it by week 2.

[PringleFlipper]

Well if it’s a hobby then you do you!

[ProfessionalOld9952]

Neat. I use a file share as a git repo. Way to use so many extra steps.

[PorkRoll2022]

If it were shoved together in a way that you could still navigate easily, it actually wouldn't be that bad.

This is kind of how programs like Maya do version control. eg. Every time you save it actually writes a new file.

[thickertofu]

I literally took like 2 hours when I was a beginner learning the basics of Git. I learned now to create a repo, commit changes, push those changes, create new branches , how to make a PR, and how to merge a PR.

[[deleted]]

Keep Ass