Long story short: I’m starting on gamedev and want to get accustomed to version control without taking too much time learning about it

I know this is kinda asking to be spoonfed the answer, but truth is I don’t have a lot of free time and wish to focus mine on not losing interest in this new hobby (I know getting stuck on details and scope is one of the main pitfalls of new gamedevs). I also want to get used to do things the right way (otherwise I wouldn’t even be thinking about it this early) anywhere I can that isn’t too distracting from the goal. At least I’m contributing discussions to the community.

I know there are a few self hosted git options, but I don’t really understand much of what using git is like, technically I “learned” to use github for version control when doing a web dev course but I couldn’t keep a single part of that segment in long term memory.

I am looking for something I can host on my server and that I can push to from godot or a gui client (from linux). I am looking to selfhost partly for the giggles (if it’s somehow too complicated I’m willing to give up on that part) and partly because I don’t want to keep my stuff on someone else’s server if I can avoid it. I’m also trying to avoid having to learn about how to properly use it for as long as I can.

I think I’ve read about gitea on here before? I’d rather avoid ai-assisted projects because of the low commitment threshold to push updates, I’m pretty sure they’re more likely to give up with the updates than caffeine fueled coders thanks to the sunk cost fallacy.

I don’t plan on publishing anything on the time being, maybe after a while I might look into it more and use a proper service, one of my long term goals is making a foss game that people want to play, but that’s long down the road, I rather learn how to make games first.

  • Bongles@lemmy.zipEnglish
    3·
    2 hours ago

    In a terminal (or git bash) that’s set to the folder your project is in (cd /path/to/your/project or something like that)

    do this one time (per device):

    git config --global user.name "Your Name"
git config --global user.email "you@example.com"

    Otherwise git will yell at you to do that anyway. Otherwise:

    git init -b main
    This starts the whole repository with a branch (-b) called main.

    git add .
    Your git repository has nothing being tracked yet, this stages all of the files. (The . means everything in the current folder and below)

    git commit -m "text that describes the commit, like initial commit for the first one"
    You’ve “staged” the changes with add, this adds them to a “commit”.

    Normally git is local, if you want them in a remote repository - like github, gitea, forgejo, etc. you’d create the remote repository there, leave it empty, and add that remote to git.

    git remote add origin https://your-server/user/project.git
    you’ve added the remote repo called origin, why origin? It’s arbitrary, do it for shits and giggles and because you don’t have to think about it, it’s the conventional name. The link comes from github or whatever service.

    You now have the remote, you have your initial files added to a commit, to actually get them to the remote repo you need to push it.

    git push -u origin main
    That pushes the commit(s) to the remote “origin” on the main branch. Do that once per project and after that when you want to push your commits you just do git push.

    This is the sort of stuff all of the software like Godot or vs codium or whatever is doing in the background when you click the buttons.

    New project

    1. Make the repo
    2. Add the changed files (they’re all changed, the repo has no commits yet and is basically empty)
    3. Create the commit with a helpful message
    4. Push the commit.

    New changes

    1. Add changed files
    2. Create commit
    3. Push commit

    There’s more to it, like reverting back to old commits when something goes wrong, Using a .gitignore file to block staging files you don’t want to, fetching and pulling, and other things that can make git kind of hard at first.