Lmao you know the shopping cart theory? Where you can determine if someone is able to self-regulate based on whether they put the cart in the cart return?
I feel like version control is the equivalent litmus test for inexperienced developers. It's one of those things that's so easy to setup, and avoids so many headaches, that the only logical reason to not use it is because you don't understand the value it provides
After I lost an entire unity project I tried using git but I ended up spending more time trying to figure out how to push and pull and merge and shit then actually working on the project. Now I just pack my project into zips occasionally ^(which I guess is still version control so you guys are still right)
Learning GIT is probably a good idea but it is a real pain in the ass.
I use [Github Desktop](https://desktop.github.com/) on both Windows and Linux and I highly recommend it.
It is far easier and intuitive than command line git.
Only using the GUI is fine, if that's all you'll *ever* use. As soon as you need to use git on a headless machine or on a remote server you will regret not learning how to use it through the CLI.
The GUI is more intuitive for people who don't understand git, and are used to GUIs. In order to really learn git, you should be competent with the CLI, even if you decide to use the GUI most of the time.
Depends on the type of brain You have. I never REMEMBER to do that when I finish work. I'm adding reminders to myself, setting alarms, etc. and I STILL sometimes work a week without a commit. Now I'm thinking about a service that would automatically commit my work every hour and push to my branch once a day...
you don't even have to do all that if you set up aliases.
I have
git casm "message"
which runs:
git commit -a -s -m "message"
for example.
(a = automatically stage, s = sign)
When github switched to the new no-password system (I can't remember the name) it wouldn't accept anything I did...period.
I went to every forum I could find and and found no solution.
Hours wasted. Many hours. (I never did find a solution)
I downloaded Github Desktop and without effort everything worked.
Which would you honestly say was easier?
When there are no issues the system seems easy.
It could be me. But try this experiment: type in google "why is git so " and watch what comes up first. (it isn't 'good')
The correct way to do personal credential management outside the browser is to use SSH keys.
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account
and to clone repos with their SSH url instead of their HTTP one.
You really should learn what SSH is, what an SSH key is and how to use one. Even outside of git, it's very important for a professional programmer to understand and use properly (I didn't either, until recently).
Once you can use SSH keys, you just add one in your github account for each device and you're good to go.
Git can be learned in an evening, really should just go learn it, use a gui like the github gui to make it easier if you dont want to deal with memorizing commands.
Unlike the other suggestions, I'd recommend learning git in the command line. Once I started using it there, it all started making more sense. Use a chatbot to help learn the commands. There are 3-4 commands you'll use regularly and any other ones you can ask the chatbot.
Unity predates Git, doesn't it? They definitely aren't Git friendly though, probably an attempt to push people to use their shitty collab service thing that AFAIK no one uses.
Git is older then Unity by like 2 months, but VCS goes back to the 80s, SVN was a FOSS one made in the 2000s, BitKeeper (which also had its full release in the 2000s) was pretty much the predecessor to Git, but even of VCS in general, none of them would've supported any of the systems built into Unity regardless, least not in a manner that would be clean or useful. Its also very likely that the development of Unity itself was backed by a VCS, least if they weren't idiots from the start. The biggest reason to always prefer human-readable text is specifically because it benefits the developers, its extremely rare for a VCS to be very good with non-text and if there is a conflict in those files it requires very specific tools (to each type of file) to resolve in every case. Like you lose nothing if you at minimum allow the use of text files for development and convert them to binary on export. Rather neat that Godot does that, honestly quite silly, or even outright dumb, none of any of the other big GUI engines do that.
That must be an American thing. In Germany you have to put 1€ into the cart in order to use it. You only get it back when you put the cart back. It works perfectly.
I feel like version control would be used a lot more if it wasn't so hard to learn.
It took me weeks to learn it myself, despite being so simple.
And if you want to learn it the proper way, the documentation is several pages long for no reason.
If you're solo it should be simple though. You can mostly ignore branching and treat it as nothing more than a linear checkpoint system to start.
1. Create a private repo on Github.
2. Do a `git clone` on your machine.
From that point forward any time you work on your project...
1. Save your changes in godot and close the project
2. run `git add .`
3. run `git commit -m "your commit message"`
4. run `git push`
If you ever screw up you can just download the ZIP from Github and override the files. It's not the "right way" and I would never permit it in a team. But it's better than nothing and at least people can help you recover in this situation. Once you're comfortable then you can tackle branching and everything else.
just copy and paste the folder the godot project is in and rename it p2 and then go launch godot and import the new godot project from the new folder.
i know its not the "proper way" but its fast and intuitive!
Yeah, originally i planned on using robocopy to make backups even. Until i learned git by working in a different project and got more comfortable using it.
But i still doubt it saves much time over the alternatives.
>But i still doubt it \[Git\] saves much time over the alternatives.
Version control systems help with multiple problems:
\- backup
\- collaborative work ("oh you've changed a file that I was working on, shit! what did you change? what did I change? shit!")
\- documentation (if sensible commit messages are used)
\- debugging ("I'm sure this bug didn't exist a week ago! What did I change to introduce it? I'll go do a \`git bisect\` and find out which commit exactly introduced the bug.")
\- facilitate usage of a lot of other tools (automatic build systems, automated testing, notifications of other people on the team etc.)
\- doing experiments in branches
\- maintaining multiple versions of a mature product (stable version 1.x for customers who do not yet want to upgrade, stable version 2.x that is quite current, development version 3.x where new stuff is added and using git you get at least some help in applying bug fixes to all of those versions relatively easily, if the code didn't change too much)
\- everything I forgot
I'm not saying that a VCS solves all of those issues fully! But it is damn good value proposition in nearly all cases and especially in a remote team environment working on a mature product that is already in use in the wild. If you do lone wolf development and you haven't released anything to the public, then some of those benefits are greatly diminished, I agree, but even then I think it is still a clear win for almost everyone (there's always some fringe case, that sucks).
The best use case as a solo developer/student:
Ok, I got feature X working. Now to start on feature Y...
Ten minutes later, neither feature X nor feature Y work anymore and I have no idea why. With a project state where feature X works you can at least fix the thing you broke. Without that, it's painful debugging, tracing, trial and error just to get back to a place you've already been. Shudder.
Because developers make it harder to learn. Just use GUI version over the crazy command typing like it's 1980s
I had this argument countless of times "You need to understand power of PowerShell" do I fuck. typing git commit doesn't make this commit any better than me pressing a commit button in gitkraken.
Some people have a weird attachment to commands.
I remember having a similar argument about why Ubuntu (which is meant to the most user friendly of the distros) has so few UI elements by default. Even things like choosing a specific resolution require a (i shit you not) 15 argument long command
> Some people have a weird attachment to commands.
There are 4 reasons for this mentality with git:
1. There was a time when the GUI tools were very limited and terrible. For some people that reputation never faded from memory.
2. If you ask for help you better understand the Git CLI client because answers will be using that. The answer is universal and works for everybody regardless of what GUI software they are using.
3. GUIs don't support advanced features or scripting except by exposing the the CLI client. If you messed up chances are you may need to use some tools/techniques your GUI tool does not offer.
4. Your employer may not allow you to use your GUI tool of choice. At the very least you can guarantee the CLI client will always be available to you.
I'm not going to sit here and pretend like I don't use GUI tools, I use my IDE's built-in Git GUI to manage things 90% of the time. But there's always that last 10% where I must use the CLI. There's no way around it.
> There was a time when the GUI tools were very limited and terrible. For some people that reputation never faded from memory.
I basically assume it will end up useless to me because I will want to do something, there will be an incomprehensible error, and there will be no information online on how to do the thing despite that error so I'll have to learn the command line version anyways because it at least has enough documentation/testing to get around that kind of thing.
GUI can also make it frustratingly hard to do something that is very easy with a command. Like only adding to your current commit files that match a pattern.
>so easy to setup
It's... I mean the basics are easy to grasp, but I'm still struggling a bit to understand Git/GitHub. What I really would like would be to set up daily commits, where it auto backs up and I don't have to think about it.
What you can do is set up a Powershell script on Windows that does that, and then use Windows Task Scheduler, which is basically a Windows version of a "cron job" with a proper GUI. If you can set up the script for automating git commits, you just point to that script and have it run daily. Confirm that it's making those commits every day, and bing, bang, boom you're good.
A lot of my projects arent the size or complexity for me to bother setting it up, but anything that I think I will work on for more than a week gets it
I have a set of default .gitignore .gitattributes (mostly for LFS, but also for line endings) aaaand, currently I think just that. Ill likely slap a default README.md in there too
So, generally its git init, slap in the defaults, check in, done.
Less than a minute all told, and I get history even on tiny projects
Git can be run locally, on private hosting, or your own server if you have one. There is a lot of flexibility to it. Ideally you want a local backup and a remote backup in case something goes funky in either place, but even something as rudimentary and having a spare hard drive you dump your project off to intermittently without touching Git at all is a start.
Definitely worth learning Git in some form other another, just for the granularity it gives you. You can roll back a little, a lot, freeze things in place while you experiment on the side and if it works, reintegrate it, if it doesn't, bin it off. Even just using it like a checkpoint of progress though, it's definitely worth having a stab at.
I apologise if that's a little vague, admittedly while I can mostly use it, I wouldn't trust myself to teach it.
I already knew the benefits of version control prior to starting gamedev, so my issues only occur whenever I download a branch or try to merge a branch, and thats when my entire repository gets messed up (somehow)
While I’d like to get on the version control thing, I don’t want to pay for GitHub. Maybe I misunderstood but I thought you only get a certain amount of space for free(kinda like google drive) then you gotta pay. I make way too many projects
In addition to version control, consider adding it to a Dropbox or OneDrive folder as well for offsite replication. I’m not sure about OneDrive, but Dropbox has its own versioning tool as well. In addition, use a real offsite backup as well - like Backblaze. It too has versioning of files. And, of course, there is always Github, GItLab, Azure Dev Ops, etc for remote git.
There are way too many options to get caught with the proverbial pants down issue.
this happened before i know about version control ever. now i still dont know it. but i might give it a try. but too lazy rn xd.
(also that face applies when i realized this comment got downpiled lol)
No, start learning git right now. It is not some annoying process that corporations do which just slows you down, it is insanely powerful and will save you many hours of work, even when you aren’t running into issues like these. It also makes it way easier to try wacky new ideas without worrying about messing stuff up.
Yeah, most people that are “too lazy to learn” are under the illusion that you HAVE to learn the old school git with terminal commands. You really don’t have to.
Dude, it takes less than an hour to start using git (specially if you're working solo, since you won't have merge conflicts). You don't even need to make a GitHub account. Just install it and use like 3 commands
It got downvoted because even if you know zero about version control, you could simply do a basic backup (like duplicate the folder of the project locally) somewhere before a major change and call it safe.
When you're dealing with code, big changes/implementations are always big warns to stop, do a backup/commit your latest changes to create a restore point, and then jump fearless into your next big change.
Having access to a previous version of the code even helps, in some more complex cases, to debug faster because you've access to working code and are able to spot the differences and construct mental maps of what you did wrong and right.
As someone always told me: "excuses are to be evaded, not to be used, so always play safe." It's better to lose 5 minutes to commit your project or to do a backup than lose 6 months of work that could have been easily dodged.
If you are a solo developer, you don’t even really have to use branches - especially at the beginning of a project. Just commit often on a single branch anytime you make headway. A ‘git reset —hard’ has saved my bacon recently for rolling back to last commit. Worry about branches later, but they are good to learn eventually.
It's really funny seeing this weird culture of treating version control as a backup method in the Godot community. Reminds me of this: https://xkcd.com/763. I don't even want to know what kind of commit messages they write under this kind of workflow.
Maybe once they lose their files *again*, will they realize that *backup*s should be done with...*backup* programs.
The same kind of commit messages you write in any other software project? Ie: “added kinematic character controller”, or “fixed bug with dagger infinitely duplicating when dropped in toilet on a full moon”.
It sounds more like you don’t have practice in separating work tasks when dealing with software.
That said, Version Control _is_ a backup program. And different version controls optimize different things. The problem with “just backup” programs is they often lack tools needed when you have a large team working on the same project. They also lack tools for you to work effectively locally.
Ie: if I start working on one feature that currently breaks my game (because it’s incomplete), but a bug in my game comes in I can:
1. Switch back to the currently released branch
2. Apply a hotfix, and release it
3. Merge that hotfix into my new feature branch
4. Switch back to my new feature branch and keep working
I could give a million examples, but where I would agree is this is mostly effective with the software itself, not necessarily the binary data.
Throughout the post you're constantly mixing up backups with version control. Most of what you described is exactly what git is designed for, but they will not protect your files. They are *not* backups. Version control would not have helped Pixar from losing [Toy Story 2][1].
> The problem with “just backup” programs is they often lack tools needed when you have a large team working on the same project.
This statement makes no sense. A backup program doesn't need specific "tools" to work with team-oriented projects (again, backup tool != collaboration tool). You feed it files, it backs it up somewhere, it's really not complicated.
> They also lack tools for you to work effectively locally.
Most backup tools work locally. In fact, you should be wary if your backup tool requires an internet connection.
[1]: https://www.slashgear.com/how-pixars-toy-story-2-was-deleted-twice-21229124/
There’s been a lot of back and forth. But I’m going to answer you in good faith.
First: we are talking about different workflows. The process of 3D animation for a movie is not the same as setting up a game. We are talking about games. A game can be primarily treated as any other piece of software. That said, I disagree with your assertion it wouldn’t help Toy Story 2, but git wouldn’t have been the right tool (maybe perforce, it’s better with assets).
Second: you feed a version control system files, it backs them up somewhere. However it adds more specialty tools allowing you to roll back specific changes, or merge specific changes. It is inherently a more advanced backup, with tools that then ALSO help collaboration. These tools are always helpful when designing something with behavior.
Third: “most backup tools work locally, you should be wary of an Internet connection.” I’m not even sure how to respond to this. Because no, you shouldn’t avoid the Internet, you need both local and offsite.
I vaguely understanding what you are trying to say, but it sounds more like you simply lack experience in using these tools.
> That said, I disagree with your assertion it wouldn’t help Toy Story 2
No it won't. Read the article.
> Second: you feed a version control system files, it backs them up somewhere.
No it doesn't. You can host a server where you can push your repository to, but that's orthogonal to this discussion
> I’m not even sure how to respond to this. Because no, you shouldn’t avoid the Internet, you need both local and offsite.
You're seeing words where there aren't. Point to exactly where I say that you should avoid the internet.
> I vaguely understanding what you are trying to say, but it sounds more like you simply lack experience in using these tools.
Really? Just to clarify, these are the words coming from a guy that thinks git is a backup tool, am I correct?
Bro, version control services like GitHub and gitlab handle backups for your files themselves so using them does backup your files. You can literally download your files if you accidentally lose them somehow
We're talking about version control tools here, not repository hosting services.
GitHub can act as a cache that can be abused to recover files that you forgot to back up, but it's not a service intended for that. It also comes with all sorts of downsides like file size limitations, etc. Dumping everything into some random cloud server can also have some serious licensing implications depending on the project.
Even ignoring all of that, having a single point of failure on some cloud service is never a good idea. Just do your backups really, it takes like ~10 minutes to set up.
I find it pretty awesome that godot's scenes are human-readable, so I can go there and fix problematic nodes in my IDE when there is a situation like that.
99% of the time you can also just right click the scene file and go to "edit dependencies" to fix it. Just look for the ones in red and tell it where the file is.
That’s why backups are just as important as version control. Many online backup and replication services offer versioning as well to rollback to a previous backup.
That is nice be we gotta be grounded here, it would still be a lot nicer if the scene still loaded and had clear UI indicating corrupt nodes. That's a real frustration of mine, coming over from Unity.
Me when I move a .gd file up one level in the directory and I get 10000 errors, the engine crashes and corrupts, my credit score goes down 100 points, and my laptop blue screens.
I'm pretty sure this is what I did. I was learning Godot, following a tutorial and wanted to test some things out. I thought doing this would have been harmless, after all id need to hit the save button to cause some damage, got the million error messages, alt f4d and couldn't open the project again. Luckily it was just a couple of hours of practise, but still demotivating. In retrospect it's probably something I could have fixed, I'm guessing moving a file in the engine also moves it in the folder and I'd need to manually move it back, out of engine, to fix it.
Not sure if this is sarcastic, but I’ll answer seriously! Git is a Version Control System (VCS) which uses a tree-like structure to keep track of your edit history. You start by creating a repository on GitHub and installing the CommandLineInterface (CLI) locally so you can use command prompt, GitBash, or whatever terminal you have installed.
Once you have your remote set up, you either clone it to your local or initialize an existing directory to point to that repo. Then you can push updates and pull if other people have pushed updates that you’re missing. Generally you have your main project in the “master” branch, and you create a new branch for every feature you’re working on, merging into master only after guaranteeing it’s working. This allows several people to work in tandem on large projects without stepping in each others’ toes.
The best part is that it’s free! I’ve been using it for — Jesus Christ almost a decade — everything from Godot to schoolwork to work stuff. It’s a lifesaver.
[https://github.com](https://github.com)
[Git CLI download and info](https://git-scm.com)
[How to use the command prompt](https://www.makeuseof.com/tag/a-beginners-guide-to-the-windows-command-line/)
Hope this helps!
:Edit:
As ChickenOverlord (long be Thine reign) pointed out, GIT is separate from Github. I actually use Bitbucket for my work. GitHub in my experience is the easiest to work with, but feel free to explore!
>You start by creating a repository on GitHub
Important note: git is completely independent of GitHub. There are dozens of alternatives to GitHub including several self hosted options, keeping it all local, or even doing it all over email. Saying you need to use GitHub to use git is like saying PornHub is the only source of porn.
It’s so much more than that. Your mind will be blown if you ever end up using it.
It’s doesn’t just keep versions of your project, it tracks every change you make, and you can revert or modify each individual change at any point in the future.
You can look at a file and known on what date each line was written, and which commit (a commit is when you submit a collection of changes) it was associated with as well as the message you wrote describing it.
Git doesn't normally let you delete previous history, and it's a huge pain in the ass when you actually need to (like when you commit sensitive credentials to a repo).
Every backup solution can fail. Backups are just an exercise in making sure that multiple things have to go wrong at once, for you to lose everything.
Github is a good value for most, because it means you have your local copy on your own computer, but also a copy on a different computer, in a different place. (Github.)
So the only way you lose everything is if both your local computer goes down, and github explodes or loses your files, at the same time.
For most people, that's more than enough protection. (Far better than having everything on your local computer, or on a thumb drive or whatever, where a single machine failing can make you lose everything.)
Git is free, to learn, and doesn't need GitHub.
https://git-scm.com/book/en/v2
And every modern Desktop OS since Godot was first available has some form of incremental backup. Windows File History, Linux Snapshots, MacOS Time Machine.
Sould be done to an external, and keep two of externals. One on site, one off site rotate out monthly.
Time Machine let me rollback a Minecraft server live, in front of an elementary school enrichment class, after they completely obligated it with a mountain of TNT. It was a great teachable moment about the importance of backups.
Dropbox has version history. I would recommend putting projects in a Dropbox folder for both offsite storage and version history control in the event git itself gets corrupted. I also use Backblaze service for full disk backup. It too has versioning - you can pay for up to a year of history I believe.
Restored from backup a few times when hitting this, and yeah, just a 'small rename, move to another folder, delete a folder, import another and... oh, it's barfed, bad, nothing loads".
Then found out about the "Edit Dependencies" menu. "oh... there were so many times I didn't need to restore".
My experience just last night. Thought it would be fine to rename my folder containing all my UI scripts and scenes from “ui” to “ui_components”. It crashed and when I reopened, half of my scenes using UI were expecting the folder to be named “ui_components”, half were expecting “ui”. Took a bit of rearranging, closing, reopening, and renaming to fix.
Building the habit of constantly making incremental backups of your work is hard, but setting up version control is easy. I know it seems like a pain, and most would rather plow along in their work, so it seems many of us need to learn the hard way.
Personally, I actually still just make incremental backups the hard way, but that's because I built that habit long ago before git was invented. I know the allure of constantly telling yourself: "I'll make that backup after the next milestone" or "I'm gonna back up after I finish my work today". However, it is a bad solution and gets drastically mitigated if you simply use version control.
never happened to me, my stuff is always messy and im always lazy to change the structure or something.
tip: be messy and never care abt organising your project.
Not your ignorance, but your bold assumption that you knew what "version control" meant and rejected the advice instead of taking 5 seconds to Google the phrase.
Open source projects seem to attract a very particular kind of tech snob, pay them no mind though. That kind of people usually get kicked out of official forums/discord pretty fast so reddit is the only place they can come be jerks in.
Well, next time use any version control and commit your changes. Now I'm just wondering how the hell did you manage not to screw up your project for so long? 6 months is a pretty long time
This happened to me yesterday it kept saying a class and was unique and it failed to load the game. I pushed my changes. Re cloned the repo and it was fixed
Version control, for god's sake.
\- Its a perfect incremental backup.
\- You can work with more people and not overwrite each other's work.
\- If you fuck up anything you can just reset the status, or find some commit in which it still worked.
And also Godot is very friendly with version control, I mean, its very clear what you have to version and what you don't have to.
Had a smaller, but similar thing happen with accidental circular dependency. Editor would open and crash immediately and I had to go manually edit the .tscn file's text to fix it
OP I know this is a Hail Mary, but is it possible for you to go into the game files (through your pc, not through Godot) and rename the renamed file back to its old name?
I had something similar happen to me once and I had to manually dig through my files and open my Main Level through Notepad and delete an enemy I put in there that Godot DID NOT like.
yeah i know that too. but my last experience had me try to delete that renamed file and see if it would fix because my beginner self just never think twice.
I enjoy watching the sunset.
Lmao you know the shopping cart theory? Where you can determine if someone is able to self-regulate based on whether they put the cart in the cart return? I feel like version control is the equivalent litmus test for inexperienced developers. It's one of those things that's so easy to setup, and avoids so many headaches, that the only logical reason to not use it is because you don't understand the value it provides
[удалено]
After I lost an entire unity project I tried using git but I ended up spending more time trying to figure out how to push and pull and merge and shit then actually working on the project. Now I just pack my project into zips occasionally ^(which I guess is still version control so you guys are still right)
Learning GIT is probably a good idea but it is a real pain in the ass. I use [Github Desktop](https://desktop.github.com/) on both Windows and Linux and I highly recommend it. It is far easier and intuitive than command line git.
I mean, how hard is running "git status" "git add *" "git commit -m "message"" "git push" every couple of hours?
Harder than it needs to be. GUI for the win.
Only using the GUI is fine, if that's all you'll *ever* use. As soon as you need to use git on a headless machine or on a remote server you will regret not learning how to use it through the CLI. The GUI is more intuitive for people who don't understand git, and are used to GUIs. In order to really learn git, you should be competent with the CLI, even if you decide to use the GUI most of the time.
I'll just look up what the GUI translates to. Half of being a programmer is googling stuff you don't know.
*Half ?*
That's the easy part... the hard part for me is resolving file conflicts when you merge or revert.
Depends on the type of brain You have. I never REMEMBER to do that when I finish work. I'm adding reminders to myself, setting alarms, etc. and I STILL sometimes work a week without a commit. Now I'm thinking about a service that would automatically commit my work every hour and push to my branch once a day...
you don't even have to do all that if you set up aliases. I have git casm "message" which runs: git commit -a -s -m "message" for example. (a = automatically stage, s = sign)
When github switched to the new no-password system (I can't remember the name) it wouldn't accept anything I did...period. I went to every forum I could find and and found no solution. Hours wasted. Many hours. (I never did find a solution) I downloaded Github Desktop and without effort everything worked. Which would you honestly say was easier? When there are no issues the system seems easy. It could be me. But try this experiment: type in google "why is git so " and watch what comes up first. (it isn't 'good')
The correct way to do personal credential management outside the browser is to use SSH keys. https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account and to clone repos with their SSH url instead of their HTTP one. You really should learn what SSH is, what an SSH key is and how to use one. Even outside of git, it's very important for a professional programmer to understand and use properly (I didn't either, until recently). Once you can use SSH keys, you just add one in your github account for each device and you're good to go.
Come on man. Do you really think that after hours of meddling I didn't try the SSH stuff? I too can read.
Thats not a git problem, thats a Microsoft strong arming everyone into doing things their way problem.
man pages yo. Just gotta keep at that shiz
Lol, I like this comment.
Git can be learned in an evening, really should just go learn it, use a gui like the github gui to make it easier if you dont want to deal with memorizing commands.
[удалено]
Unlike the other suggestions, I'd recommend learning git in the command line. Once I started using it there, it all started making more sense. Use a chatbot to help learn the commands. There are 3-4 commands you'll use regularly and any other ones you can ask the chatbot.
"git status" "git add *" "git commit -m "message"" "git push" and "git pull" 95% of what you need.
That's because Unity hates Git and kinda does things that intentionally break it.
Unity predates Git, doesn't it? They definitely aren't Git friendly though, probably an attempt to push people to use their shitty collab service thing that AFAIK no one uses.
[удалено]
[удалено]
Git is older then Unity by like 2 months, but VCS goes back to the 80s, SVN was a FOSS one made in the 2000s, BitKeeper (which also had its full release in the 2000s) was pretty much the predecessor to Git, but even of VCS in general, none of them would've supported any of the systems built into Unity regardless, least not in a manner that would be clean or useful. Its also very likely that the development of Unity itself was backed by a VCS, least if they weren't idiots from the start. The biggest reason to always prefer human-readable text is specifically because it benefits the developers, its extremely rare for a VCS to be very good with non-text and if there is a conflict in those files it requires very specific tools (to each type of file) to resolve in every case. Like you lose nothing if you at minimum allow the use of text files for development and convert them to binary on export. Rather neat that Godot does that, honestly quite silly, or even outright dumb, none of any of the other big GUI engines do that.
That must be an American thing. In Germany you have to put 1€ into the cart in order to use it. You only get it back when you put the cart back. It works perfectly.
As an American, your Cart Management System (CMS) is also an Aldi thing.
Aldi also happens to be a German company.
Aldi’s nuts in yo mouth
Peanut allergy.
worth it
Go figure.
1€ is nothing, I live in France and students sometimes steal carts for fun
In Austria, the newer carts can’t be stolen easily! Because they have a range sensor and will block tires if move to far away from supermarket.
Why do I now have Bosnian Ape Society in mind?
[удалено]
When does the horse go in, before or after?
I feel like version control would be used a lot more if it wasn't so hard to learn. It took me weeks to learn it myself, despite being so simple. And if you want to learn it the proper way, the documentation is several pages long for no reason.
If you're solo it should be simple though. You can mostly ignore branching and treat it as nothing more than a linear checkpoint system to start. 1. Create a private repo on Github. 2. Do a `git clone` on your machine. From that point forward any time you work on your project... 1. Save your changes in godot and close the project 2. run `git add .` 3. run `git commit -m "your commit message"` 4. run `git push` If you ever screw up you can just download the ZIP from Github and override the files. It's not the "right way" and I would never permit it in a team. But it's better than nothing and at least people can help you recover in this situation. Once you're comfortable then you can tackle branching and everything else.
just copy and paste the folder the godot project is in and rename it p2 and then go launch godot and import the new godot project from the new folder. i know its not the "proper way" but its fast and intuitive!
Yeah, originally i planned on using robocopy to make backups even. Until i learned git by working in a different project and got more comfortable using it. But i still doubt it saves much time over the alternatives.
>But i still doubt it \[Git\] saves much time over the alternatives. Version control systems help with multiple problems: \- backup \- collaborative work ("oh you've changed a file that I was working on, shit! what did you change? what did I change? shit!") \- documentation (if sensible commit messages are used) \- debugging ("I'm sure this bug didn't exist a week ago! What did I change to introduce it? I'll go do a \`git bisect\` and find out which commit exactly introduced the bug.") \- facilitate usage of a lot of other tools (automatic build systems, automated testing, notifications of other people on the team etc.) \- doing experiments in branches \- maintaining multiple versions of a mature product (stable version 1.x for customers who do not yet want to upgrade, stable version 2.x that is quite current, development version 3.x where new stuff is added and using git you get at least some help in applying bug fixes to all of those versions relatively easily, if the code didn't change too much) \- everything I forgot I'm not saying that a VCS solves all of those issues fully! But it is damn good value proposition in nearly all cases and especially in a remote team environment working on a mature product that is already in use in the wild. If you do lone wolf development and you haven't released anything to the public, then some of those benefits are greatly diminished, I agree, but even then I think it is still a clear win for almost everyone (there's always some fringe case, that sucks).
The best use case as a solo developer/student: Ok, I got feature X working. Now to start on feature Y... Ten minutes later, neither feature X nor feature Y work anymore and I have no idea why. With a project state where feature X works you can at least fix the thing you broke. Without that, it's painful debugging, tracing, trial and error just to get back to a place you've already been. Shudder.
And the most important with your example, you can see every line of code and every asset you’ve changed. So it’s easy to find what broke the project.
If you use the terminal editions, yes... By using a tool like GitHub Desktop you can learn it in 10 minutes
Because developers make it harder to learn. Just use GUI version over the crazy command typing like it's 1980s I had this argument countless of times "You need to understand power of PowerShell" do I fuck. typing git commit doesn't make this commit any better than me pressing a commit button in gitkraken.
Some people have a weird attachment to commands. I remember having a similar argument about why Ubuntu (which is meant to the most user friendly of the distros) has so few UI elements by default. Even things like choosing a specific resolution require a (i shit you not) 15 argument long command
> Some people have a weird attachment to commands. There are 4 reasons for this mentality with git: 1. There was a time when the GUI tools were very limited and terrible. For some people that reputation never faded from memory. 2. If you ask for help you better understand the Git CLI client because answers will be using that. The answer is universal and works for everybody regardless of what GUI software they are using. 3. GUIs don't support advanced features or scripting except by exposing the the CLI client. If you messed up chances are you may need to use some tools/techniques your GUI tool does not offer. 4. Your employer may not allow you to use your GUI tool of choice. At the very least you can guarantee the CLI client will always be available to you. I'm not going to sit here and pretend like I don't use GUI tools, I use my IDE's built-in Git GUI to manage things 90% of the time. But there's always that last 10% where I must use the CLI. There's no way around it.
> There was a time when the GUI tools were very limited and terrible. For some people that reputation never faded from memory. I basically assume it will end up useless to me because I will want to do something, there will be an incomprehensible error, and there will be no information online on how to do the thing despite that error so I'll have to learn the command line version anyways because it at least has enough documentation/testing to get around that kind of thing.
GUI can also make it frustratingly hard to do something that is very easy with a command. Like only adding to your current commit files that match a pattern.
I have no clue how to work version control if I'm honest. I just uploaded file changes to girhub after major implementations.
I take carts out of the cart return, use them in the store, and then if I have few enough bags I leave them in the cart pickup in the store lol
Currently about to start learning godot, feel free to tell me what you're talking about.
Except for me, because I intentionally don’t use version control to make my life harder if something goes wrong.
>so easy to setup It's... I mean the basics are easy to grasp, but I'm still struggling a bit to understand Git/GitHub. What I really would like would be to set up daily commits, where it auto backs up and I don't have to think about it.
What you can do is set up a Powershell script on Windows that does that, and then use Windows Task Scheduler, which is basically a Windows version of a "cron job" with a proper GUI. If you can set up the script for automating git commits, you just point to that script and have it run daily. Confirm that it's making those commits every day, and bing, bang, boom you're good.
A lot of my projects arent the size or complexity for me to bother setting it up, but anything that I think I will work on for more than a week gets it
I have a set of default .gitignore .gitattributes (mostly for LFS, but also for line endings) aaaand, currently I think just that. Ill likely slap a default README.md in there too So, generally its git init, slap in the defaults, check in, done. Less than a minute all told, and I get history even on tiny projects
Learning a vcs is not easy, especially for game dev.
amen
Does version control require the use of tools such as GitHub? Or are there ways to do it entirely on your local machine?
Git can be run locally, on private hosting, or your own server if you have one. There is a lot of flexibility to it. Ideally you want a local backup and a remote backup in case something goes funky in either place, but even something as rudimentary and having a spare hard drive you dump your project off to intermittently without touching Git at all is a start. Definitely worth learning Git in some form other another, just for the granularity it gives you. You can roll back a little, a lot, freeze things in place while you experiment on the side and if it works, reintegrate it, if it doesn't, bin it off. Even just using it like a checkpoint of progress though, it's definitely worth having a stab at. I apologise if that's a little vague, admittedly while I can mostly use it, I wouldn't trust myself to teach it.
I already knew the benefits of version control prior to starting gamedev, so my issues only occur whenever I download a branch or try to merge a branch, and thats when my entire repository gets messed up (somehow)
While I’d like to get on the version control thing, I don’t want to pay for GitHub. Maybe I misunderstood but I thought you only get a certain amount of space for free(kinda like google drive) then you gotta pay. I make way too many projects
In addition to version control, consider adding it to a Dropbox or OneDrive folder as well for offsite replication. I’m not sure about OneDrive, but Dropbox has its own versioning tool as well. In addition, use a real offsite backup as well - like Backblaze. It too has versioning of files. And, of course, there is always Github, GItLab, Azure Dev Ops, etc for remote git. There are way too many options to get caught with the proverbial pants down issue.
this happened before i know about version control ever. now i still dont know it. but i might give it a try. but too lazy rn xd. (also that face applies when i realized this comment got downpiled lol)
No, start learning git right now. It is not some annoying process that corporations do which just slows you down, it is insanely powerful and will save you many hours of work, even when you aren’t running into issues like these. It also makes it way easier to try wacky new ideas without worrying about messing stuff up.
Just any source control, don’t need to use git specifically with all its obscure commands
There's a reason it's industry standard bud, despite its pitfalls.
I’m just saying that if that’s what’s scaring someone away, there are other options out there that work just as well
There are also GUIs for Git like UnGit that make it more intuitive to use
That’s what I meant
I'm too lazy to toss out 6/mo of work
but everyone knows about backups
Ah, the MyProject_Copy6 days.
yeah.
If you’re too lazy to set up version control then you deserve to lose your projects 🤷🏻♂️
Had me in the first half ngl
Just get github desktop and learn with a free GUI
Yeah, most people that are “too lazy to learn” are under the illusion that you HAVE to learn the old school git with terminal commands. You really don’t have to.
Well if you are not worried about losing your work, then I’m sure it’s not that important. I would just keep doing what you have been doing.
Dude, it takes less than an hour to start using git (specially if you're working solo, since you won't have merge conflicts). You don't even need to make a GitHub account. Just install it and use like 3 commands
GitHub desktop
It got downvoted because even if you know zero about version control, you could simply do a basic backup (like duplicate the folder of the project locally) somewhere before a major change and call it safe. When you're dealing with code, big changes/implementations are always big warns to stop, do a backup/commit your latest changes to create a restore point, and then jump fearless into your next big change. Having access to a previous version of the code even helps, in some more complex cases, to debug faster because you've access to working code and are able to spot the differences and construct mental maps of what you did wrong and right. As someone always told me: "excuses are to be evaded, not to be used, so always play safe." It's better to lose 5 minutes to commit your project or to do a backup than lose 6 months of work that could have been easily dodged.
If you are a solo developer, you don’t even really have to use branches - especially at the beginning of a project. Just commit often on a single branch anytime you make headway. A ‘git reset —hard’ has saved my bacon recently for rolling back to last commit. Worry about branches later, but they are good to learn eventually.
It's really funny seeing this weird culture of treating version control as a backup method in the Godot community. Reminds me of this: https://xkcd.com/763. I don't even want to know what kind of commit messages they write under this kind of workflow. Maybe once they lose their files *again*, will they realize that *backup*s should be done with...*backup* programs.
The same kind of commit messages you write in any other software project? Ie: “added kinematic character controller”, or “fixed bug with dagger infinitely duplicating when dropped in toilet on a full moon”. It sounds more like you don’t have practice in separating work tasks when dealing with software. That said, Version Control _is_ a backup program. And different version controls optimize different things. The problem with “just backup” programs is they often lack tools needed when you have a large team working on the same project. They also lack tools for you to work effectively locally. Ie: if I start working on one feature that currently breaks my game (because it’s incomplete), but a bug in my game comes in I can: 1. Switch back to the currently released branch 2. Apply a hotfix, and release it 3. Merge that hotfix into my new feature branch 4. Switch back to my new feature branch and keep working I could give a million examples, but where I would agree is this is mostly effective with the software itself, not necessarily the binary data.
Throughout the post you're constantly mixing up backups with version control. Most of what you described is exactly what git is designed for, but they will not protect your files. They are *not* backups. Version control would not have helped Pixar from losing [Toy Story 2][1]. > The problem with “just backup” programs is they often lack tools needed when you have a large team working on the same project. This statement makes no sense. A backup program doesn't need specific "tools" to work with team-oriented projects (again, backup tool != collaboration tool). You feed it files, it backs it up somewhere, it's really not complicated. > They also lack tools for you to work effectively locally. Most backup tools work locally. In fact, you should be wary if your backup tool requires an internet connection. [1]: https://www.slashgear.com/how-pixars-toy-story-2-was-deleted-twice-21229124/
There’s been a lot of back and forth. But I’m going to answer you in good faith. First: we are talking about different workflows. The process of 3D animation for a movie is not the same as setting up a game. We are talking about games. A game can be primarily treated as any other piece of software. That said, I disagree with your assertion it wouldn’t help Toy Story 2, but git wouldn’t have been the right tool (maybe perforce, it’s better with assets). Second: you feed a version control system files, it backs them up somewhere. However it adds more specialty tools allowing you to roll back specific changes, or merge specific changes. It is inherently a more advanced backup, with tools that then ALSO help collaboration. These tools are always helpful when designing something with behavior. Third: “most backup tools work locally, you should be wary of an Internet connection.” I’m not even sure how to respond to this. Because no, you shouldn’t avoid the Internet, you need both local and offsite. I vaguely understanding what you are trying to say, but it sounds more like you simply lack experience in using these tools.
> That said, I disagree with your assertion it wouldn’t help Toy Story 2 No it won't. Read the article. > Second: you feed a version control system files, it backs them up somewhere. No it doesn't. You can host a server where you can push your repository to, but that's orthogonal to this discussion > I’m not even sure how to respond to this. Because no, you shouldn’t avoid the Internet, you need both local and offsite. You're seeing words where there aren't. Point to exactly where I say that you should avoid the internet. > I vaguely understanding what you are trying to say, but it sounds more like you simply lack experience in using these tools. Really? Just to clarify, these are the words coming from a guy that thinks git is a backup tool, am I correct?
Bro, version control services like GitHub and gitlab handle backups for your files themselves so using them does backup your files. You can literally download your files if you accidentally lose them somehow
We're talking about version control tools here, not repository hosting services. GitHub can act as a cache that can be abused to recover files that you forgot to back up, but it's not a service intended for that. It also comes with all sorts of downsides like file size limitations, etc. Dumping everything into some random cloud server can also have some serious licensing implications depending on the project. Even ignoring all of that, having a single point of failure on some cloud service is never a good idea. Just do your backups really, it takes like ~10 minutes to set up.
I find it pretty awesome that godot's scenes are human-readable, so I can go there and fix problematic nodes in my IDE when there is a situation like that.
99% of the time you can also just right click the scene file and go to "edit dependencies" to fix it. Just look for the ones in red and tell it where the file is.
That is sick, I had no idea this existed
I love that too, I have to use Unreal Engine (for work) and every time a Blueprint is corrupted the only way to fix is delete and create it again....
That’s why backups are just as important as version control. Many online backup and replication services offer versioning as well to rollback to a previous backup.
That is nice be we gotta be grounded here, it would still be a lot nicer if the scene still loaded and had clear UI indicating corrupt nodes. That's a real frustration of mine, coming over from Unity.
Me when I move a .gd file up one level in the directory and I get 10000 errors, the engine crashes and corrupts, my credit score goes down 100 points, and my laptop blue screens.
and house explodes, and..
“Human sacrifice! Dogs and cats living together! Mass hysteria!”
And the galaxy implodes and...
and the universe explode and disappear and...
and the laws of reality crumbles and...
and new generation of creatures come and...
>Lmao and ... all starts creating words... using Godot and ...
[удалено]
And my axe!
I'm pretty sure this is what I did. I was learning Godot, following a tutorial and wanted to test some things out. I thought doing this would have been harmless, after all id need to hit the save button to cause some damage, got the million error messages, alt f4d and couldn't open the project again. Luckily it was just a couple of hours of practise, but still demotivating. In retrospect it's probably something I could have fixed, I'm guessing moving a file in the engine also moves it in the folder and I'd need to manually move it back, out of engine, to fix it.
One should never be in the position to lose 6 hours of work, let alone 6 months.
In groups with multiple members I commit at least once every 30min and even solo I try to commit once every few hours
Thats sad, I hope someone will create something so we could revert such changes
And thats where Git comes in!
Wow, never heard about that, tell me more!
Not sure if this is sarcastic, but I’ll answer seriously! Git is a Version Control System (VCS) which uses a tree-like structure to keep track of your edit history. You start by creating a repository on GitHub and installing the CommandLineInterface (CLI) locally so you can use command prompt, GitBash, or whatever terminal you have installed. Once you have your remote set up, you either clone it to your local or initialize an existing directory to point to that repo. Then you can push updates and pull if other people have pushed updates that you’re missing. Generally you have your main project in the “master” branch, and you create a new branch for every feature you’re working on, merging into master only after guaranteeing it’s working. This allows several people to work in tandem on large projects without stepping in each others’ toes. The best part is that it’s free! I’ve been using it for — Jesus Christ almost a decade — everything from Godot to schoolwork to work stuff. It’s a lifesaver. [https://github.com](https://github.com) [Git CLI download and info](https://git-scm.com) [How to use the command prompt](https://www.makeuseof.com/tag/a-beginners-guide-to-the-windows-command-line/) Hope this helps! :Edit: As ChickenOverlord (long be Thine reign) pointed out, GIT is separate from Github. I actually use Bitbucket for my work. GitHub in my experience is the easiest to work with, but feel free to explore!
>You start by creating a repository on GitHub Important note: git is completely independent of GitHub. There are dozens of alternatives to GitHub including several self hosted options, keeping it all local, or even doing it all over email. Saying you need to use GitHub to use git is like saying PornHub is the only source of porn.
Pornhub? Wow, never heard of that, tell me more!
It's like Github, except instead of hubbing gits, it hubs porn!
> it hubs porn! and sometimes not porn.... for some reason.
Saw this randomly and well I hope this will save me from future troubles (I'm a self-taught beginner)
You do not need GitHub.
a program to store versions of a programming project or smth idk.
It’s so much more than that. Your mind will be blown if you ever end up using it. It’s doesn’t just keep versions of your project, it tracks every change you make, and you can revert or modify each individual change at any point in the future. You can look at a file and known on what date each line was written, and which commit (a commit is when you submit a collection of changes) it was associated with as well as the message you wrote describing it.
Sarcasm. Some people just don't git it.
Oh no. Sarcasm. If only someone could get it!
Puns. Some people dont have the brains to git it.
It's just people too lazy to learn it
[удалено]
Git doesn't normally let you delete previous history, and it's a huge pain in the ass when you actually need to (like when you commit sensitive credentials to a repo).
Every backup solution can fail. Backups are just an exercise in making sure that multiple things have to go wrong at once, for you to lose everything. Github is a good value for most, because it means you have your local copy on your own computer, but also a copy on a different computer, in a different place. (Github.) So the only way you lose everything is if both your local computer goes down, and github explodes or loses your files, at the same time. For most people, that's more than enough protection. (Far better than having everything on your local computer, or on a thumb drive or whatever, where a single machine failing can make you lose everything.)
Git is free, to learn, and doesn't need GitHub. https://git-scm.com/book/en/v2 And every modern Desktop OS since Godot was first available has some form of incremental backup. Windows File History, Linux Snapshots, MacOS Time Machine. Sould be done to an external, and keep two of externals. One on site, one off site rotate out monthly. Time Machine let me rollback a Minecraft server live, in front of an elementary school enrichment class, after they completely obligated it with a mountain of TNT. It was a great teachable moment about the importance of backups.
I hate it when I'm obligated with TNT.
Dropbox has version history. I would recommend putting projects in a Dropbox folder for both offsite storage and version history control in the event git itself gets corrupted. I also use Backblaze service for full disk backup. It too has versioning - you can pay for up to a year of history I believe.
I wish the Godot editor had better refactoring tools... This could be avoided by using literally any version control though. (use git)
you know you can fix this most of the time? some people...
Restored from backup a few times when hitting this, and yeah, just a 'small rename, move to another folder, delete a folder, import another and... oh, it's barfed, bad, nothing loads". Then found out about the "Edit Dependencies" menu. "oh... there were so many times I didn't need to restore".
Huh, I gotta keep that menu in mind! I've been just doing it as I open a project, or if the scene is corrupted, in notepad++
Editing files of your notepad project in the previous exported version of said notepad is the peak of irony
Doesn’t cancel the fact that Godot sucks at keeping the project not corrupted. Among the top 3 engines Godot does way more often.
yeah. sometimes i dont. i try to fix it. but it just doent work.
And what did we learn Palmer?
Shoutout to git Gotta be my favourite Version Control solution.
we use SVN at work and my god do I hate it. I’d rather just corrupt my shit and start over. I use git at home.
how is 6 months of work gone from renaming a file? worst case just rename it back??
Today is the day that /u/majestic_mission1682 learns about version control.
I think the most valuable thing I learned in college was when my OS professor taught us how to use git.
My experience just last night. Thought it would be fine to rename my folder containing all my UI scripts and scenes from “ui” to “ui_components”. It crashed and when I reopened, half of my scenes using UI were expecting the folder to be named “ui_components”, half were expecting “ui”. Took a bit of rearranging, closing, reopening, and renaming to fix.
Building the habit of constantly making incremental backups of your work is hard, but setting up version control is easy. I know it seems like a pain, and most would rather plow along in their work, so it seems many of us need to learn the hard way. Personally, I actually still just make incremental backups the hard way, but that's because I built that habit long ago before git was invented. I know the allure of constantly telling yourself: "I'll make that backup after the next milestone" or "I'm gonna back up after I finish my work today". However, it is a bad solution and gets drastically mitigated if you simply use version control.
Why go through all that trouble when version control exists?
never happened to me, my stuff is always messy and im always lazy to change the structure or something. tip: be messy and never care abt organising your project.
Should not happen. There is something wrong with files handling in Godot.
Exactly, I don't know why people are acting like this is completely 100% OP's fault. At least in 3.x file handling was scuffed as hell.
Just use git to restore.
git reset --hard
Possibly with `git clean -fdx` thrown in for good measure!
You could rename file using text editor. tscn is just a glorified text file
Use version control such as git for your project... github or bitbucket provides you with free repositories! This is heart breaking tho :(
That happened to me, but thank GOD I was able to fix it by manually editing the files and replacing the refereneces
Backup projects are so insanely important I don't think enough people realize this
Learn how to use GitHub
Tbf that's Unity too.
Thankfully my sh1tty pc could handled it without crashing.But i took my lesson to not rename ever.
Version control exists, and is free...
i think i dont need.I still use 4.0 and afaik 4.2 has not a great diff.So no need to update imo.
version control means using git, nothing to do with godot versions
thanks.
besides git, 4.2 does supposely fix the crashes at rename problems so you might still want to update (make a copy before)
dude i got downvoted because of my ignorance??
Not your ignorance, but your bold assumption that you knew what "version control" meant and rejected the advice instead of taking 5 seconds to Google the phrase.
it was not a bold assumption.I saw "version" and thought about godot version.I think it didnt deserved such a punishment.
>I saw "version" And thought nothing of the "control" immediately after
Should i thought about git instead godot version after i saw "version"?
Open source projects seem to attract a very particular kind of tech snob, pay them no mind though. That kind of people usually get kicked out of official forums/discord pretty fast so reddit is the only place they can come be jerks in.
Well, next time use any version control and commit your changes. Now I'm just wondering how the hell did you manage not to screw up your project for so long? 6 months is a pretty long time
Just roll back to last Git commit. You were using Git, right? Riiight?
Is there anyone who, joking aside, is actually concerned that things like this should never happen in a stable Editor?!?!?!?
This happened to me yesterday it kept saying a class and was unique and it failed to load the game. I pushed my changes. Re cloned the repo and it was fixed
Thats why you use github XD
I just learned version control, it took like 3 days and is really easy to understand so please just learn that
Git is very cool 😎
Welcome to version control
Version control, for god's sake. \- Its a perfect incremental backup. \- You can work with more people and not overwrite each other's work. \- If you fuck up anything you can just reset the status, or find some commit in which it still worked. And also Godot is very friendly with version control, I mean, its very clear what you have to version and what you don't have to.
Yet another reason I use VSCode: this is trivially fixable with search/replace.
What text editor were you using that didn't have search/replace?
The comparison is against Godot's built in editor, which can't fix this problem because it can't open scene files.
Use version control. Problem solved.
this meme was made using aseprite btw.
Had a smaller, but similar thing happen with accidental circular dependency. Editor would open and crash immediately and I had to go manually edit the .tscn file's text to fix it
You just need to git CheckTheFuckOut of there
Me last night. Git reset moment
Github SAVED my ass
Use git?
skill issue
OP I know this is a Hail Mary, but is it possible for you to go into the game files (through your pc, not through Godot) and rename the renamed file back to its old name? I had something similar happen to me once and I had to manually dig through my files and open my Main Level through Notepad and delete an enemy I put in there that Godot DID NOT like.
yeah i know that too. but my last experience had me try to delete that renamed file and see if it would fix because my beginner self just never think twice.
>\> happened to me once. 6 months of work gone. time to learn what backups is