this post was submitted on 22 May 2025
30 points (94.1% liked)

Godot

6656 readers
31 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 2 years ago
MODERATORS
top 31 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 10 hours ago

We use perforce at work (I use git with smartgit and TortoiseGit UI, whatever I feel like) on unity I use a package called wise for unity, which is really cool and I wish would exist in Godot.

We use perforce because we have a lot of unreal and unity and admittedly git is really bad with big binaries. It was never designed for that and git lfs ist basically just a bandaid.

In general for gamedev you'll run into a problem that a scene will be modified by 2 people. For that it is good to have perforce, as it locks a file and will tell you, that someone is working on it. Git lfs has something similar, but the again. This file locking is not yet supported by Godot.

But yes for unity and unreal at work... Even if perforce is expensive and not open source and I miss git-branches, it is an important tool and was worth the money for a company.

For your own small projects I recommend git with git-lfs

[–] [email protected] 1 points 18 hours ago

I mostly use git and I've recently been exploring anchorpoint as a way to bridge the gap between me and the less technical friends. It's does the job reallt well and I've been happy with it so far. It being a wrapper around a git repo is a very convenient compromise - I get to pick my hosting, use CLI, while other members of the team can use a more robust visual program.

[–] [email protected] 1 points 22 hours ago

SmartGit - lets you see the commands it's running and has a fairly decent toolset for rebasing (but I stopped recommending them for awhile when they delisted their perpetual licensing. It looks like as of writing it's returned but only allows for 1-3 years of updates depending on how many years you buy)

I've had my eyes on lazygit and gitui as a cli supplement

On a different note, I wish git lfs wasn't such a pita. Orphaned pointers living forever on GitHub and eating up all your quota with no way to recover unless you DELETE the repo lol

[–] [email protected] 3 points 1 day ago

Git here. Subversion for a while before that. And source safe, or as I like to say source "safe", before that.

But maybe a better question would be, what source control hosting site (if any) do you use? And do any of them not forcibly use your code to train their AI?

[–] [email protected] 6 points 1 day ago* (last edited 1 day ago) (1 children)

I've been trying out Jujutsu recently.

It's compatible with git repos. The workflow takes a little while to get used to but can be nicer to work with.

[–] [email protected] 2 points 1 day ago (1 children)

can be nicer

Understatement. It solves almost every problem I've ever had with git.

  1. No more destructive commands. jj undo or jj op restore can always put you back into a good state.
  2. Merge conflicts can be ignored until you want to resolve them.
  3. No "unstaged files" to deal with. Just keep your .gitignores up to date and jj automatically tracks new files.
  4. Rebasing and patch management is just incredibly simple.
  5. It actually has a nice default view of the commit graph.

I used to use StackedGit for a while before switching to Jujutusu. While stg is nice, I think jj is a huge improvement.

[–] [email protected] 1 points 22 hours ago (1 children)

Aside from the obvious cases like pruning or garbage collection that remove orphaned or dangling commits, is there anything else destructive that git reflog can't help recover from?

[–] [email protected] 1 points 15 hours ago

I probably can't give a good technical comparison of the power of git reflog vs jj op log, but I find jj op log much easier to use.

[–] [email protected] 33 points 2 days ago (1 children)

Project.py

Project-v2.py

Project-v2-done.py

Project-v2.1-FINAL.py

Project-v3-FINAL-FINAL.py

Project-USE THIS ONE!.py

[–] [email protected] 3 points 2 days ago (1 children)

Hahahaha, I know what you mean

[–] [email protected] 0 points 22 hours ago

I use git:

branches

master
main
deployment_<timestamp>
pre-master
adding_latest_feature
testing
[–] [email protected] 1 points 1 day ago

Git at work.

Mercurial for my own stuff.

[–] [email protected] 1 points 1 day ago

Perforce when I was doing it professionally but now for hobby just github desktop.

[–] [email protected] 21 points 2 days ago
[–] [email protected] 1 points 1 day ago

Git for pleasure, Perforce for dayjob

[–] [email protected] 12 points 2 days ago* (last edited 2 days ago) (2 children)

Magit, which is the best Git porcelain around. Git, because it has an unparalleled free-software ecosystem of developer tools that work with it.

Why is Git's free-software ecosystem so much better than all the other VCSen?

Largely because of marketing (the maker of Linux made this! hey look, GitHub!), but also because it has a solid internal data model that quickly proved to experts that it is fast and flexible and reliable.

Git's command-line interface is atrocious compared to contemporary DVCSen. This was seen originally as no problem because Git developers intentionally released it as the “plumbing” for a VCS, intending that other motivated projects would create various VCS “porcelain” for various user audiences. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain The interface with sensible operations and coherent interface language, resides in that “porcelain”, which the Git developers explicitly said they were not focussed on creating.

But, of course, the “plumbing” command line interface itself immediately became the primary way people were told to use Git, and the “porcelain” applications had much slower development and nowhere near the universal recognition of Git. So either people didn't learn Git (learning only a couple of operations in a web app, for example), or to learn Git they were required to use the dreadful user-hostile default “plumbing” commands. It became cemented as the primary way to learn Git for many years.

I was a holdout with Bazaar VCS for quite a while, because its command-line interface dealt in coherent user-facing language and consistent commands and options. It was deliberately designed to first have a good command-line UI, and make a solid DVCS under that. Which it did, quite well; but it was no match for the market forces behind Git.

Well, eventually I found that Magit is the best porcelain for Git, and now I have my favourite VCS.

[–] [email protected] 2 points 1 day ago

Upvoted for bazaar. Even before git existed bzr and qbzr on windows were more user friendly than git with any gui is now.

[–] jerkface 0 points 2 days ago

If it weren't for magit, I'd probably STILL be using hg.

[–] [email protected] 9 points 2 days ago
[–] [email protected] 1 points 1 day ago
[–] [email protected] 7 points 2 days ago
[–] [email protected] 2 points 2 days ago
[–] [email protected] 5 points 2 days ago

I don't use version control.

just kiddingI use git.

[–] [email protected] 4 points 2 days ago
[–] [email protected] 1 points 2 days ago (1 children)
[–] jerkface 0 points 2 days ago

I often use RCS because it is (until recently?) built in to the distribution, and a quick "ci -l foo" is in every way superior to "cp foo foo.save" without having a bunch of the housework required to support git.

[–] [email protected] 1 points 2 days ago

Git with Fork as a client.

[–] [email protected] 1 points 2 days ago

Git / TortoiseGit

[–] [email protected] 1 points 2 days ago
[–] YurkshireLad 1 points 2 days ago

I used to use the OpenVMS file system for informal version control, while I was developing something and before it was ready to be committed to the repository.

[–] jerkface 0 points 2 days ago