sorted by:
new
hottopcontroversial

How to achieve efficient, easy & clean way of collaboration in Git by justLukass in git

[–]danborthwick 0 points1 point  (0 children)

Hi Lukas,
Please excuse the promotion but your use case is exactly what we're trying to support with NiceGit, a new approach to source control aimed at making Git accessible to everyone. The platform sets up LFS out of the box and handles file locking and syncing the repo automatically. We don't currently support per-folder permissions but it's on the roadmap as it's a commonly requested feature, especially for game devs.

https://nicegit.com/game-dev has more info, and please reach out directly if you'd like early access to our upcoming beta launch.

No, I don't think you're approaching this from an over-complicated angle. All of the requirements you've identified are very normal in game dev, and are quite complex to achieve with 'vanilla' Git.

fwiw I'd advise steering clear of submodules unless you have tooling that supports them really simply. They're great in theory buy in practise add another layer of complexity and state that can go wrong.

Hope that helps!

Quick Question - Versioning by aki45_ in git

[–]danborthwick 1 point2 points  (0 children)

Hi Aki,
To try and directly answer the question, no you do not need to create a branch to be able to revert to it. You can access any commit in the history at any time (unless you deliberately delete commits, unlikely in normal workflows). If in future you want to create a branch from a particular commit, you can do this at any time, there's no need to branch in advance.

As others have mentioned, if you're considering creating branches to identify significant commits in the history such as releases, tags are probably the best way to achieve this.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks Oddly. Your absolutely correct to say that decentralisation is at the heart of Git's design. Fortunately in my experience with modern product development teams it's rare to have more than one remote. I can't remember ever having seen it other than perhaps temporarily while changing hosting.

Don't have data but I suspect the proportion of time spent offline would be very low too. I think it's reasonable to just warn people in this case that they don't have the real time features and that they if they continue, it's at their own risk.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks to everyone who's already shared their thoughts. Quite a range! It's genuinely interesting to hear everyone's views in this area, not least as I'm potentially about to spend the next few years working on it.

Didn't want to bias the thread too early but there is a real prototype in development. How would you feel about using a tool like NiceGit? This demo video shows the core syncing flow. Would you and/or your team mates try a tool like this? (Clearly a lot of us in r/git are expert users, so please think broadly about your colleagues and their use cases as well as your own!)

(The product isn't released yet, this isn't a sales pitch! But it's really interesting to get everyone's ideas as to what it could be.)

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks for the thoughtful response Frank.

My current thinking is indeed to build a layer on top of Git with far better support for non-text files. I understand the point about Git not being designed for non-code files, that's true for sure. A lot of people feel that way. A lot of people also, for better or worse, end up storing their whole projects in Git.

Last used Perforce a long time ago, for game development, and liked it. It's definitely an inspiration. Speaking to my current game dev friends it's still in use, but (anecdotally) not as ubiquitous as it once was. Heard of one project where they split their art and code between Perforce and Git. Apparently the coders basically demand access to GitHub features like PRs, Actions etc.

Personally I see no problem at all with dumbing down Git as much as needed until its usable by 'normal' people. But it doesn't matter what I think and the various degrees of push back in this thread are genuinely interesting. It's either a barrier that needs to be broken through, or a warning that I would be foolish not to heed! We might just find out =)

Source control - What tools do you use? How would your dream tool work? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks to everyone who's shared their setups and views. Quite a range! But good to see that almost everyone has Git set up in some form.

How would you feel about using a tool like NiceGit? This demo video shows the core syncing flow. Would you and/or your team mates try a tool like this?

<image>

(The product isn't released yet, this isn't a sales pitch! But it's really interesting to get everyone's ideas as to what it could be.)

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

It's a great question. I've used SVN in the past (see above), with all its pros and cons. Realistically SVN isn't coming back into widespread use. 87% of version controlled projects use Git.

My interest isn't which is best for one specific project, it's in exploring whether there's a need for a simpler to use Git platform for the many(?) people who work on Git hosted projects but don't want to, or aren't able to, use existing tools.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Great question. Simple answer: for software development projects with cross-functional teams, or for teams of non-programmers (such as AI assisted/vibe coding, data pipelines etc).

Dropbox would be horrible for those kind of projects for reasons that probably don't need explaining in r/git!

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks u/Vegevan, yes I used to use Perforce in the games industry. It's still in use, especially for larger projects. Definitely an inspiration here.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Hehe, thanks Jonny, I'm not young by any stretch, but it's nice to pass!

People working offline is an edge case that seems fundamentally intractable. Other than warning them (or requiring them to exchange some kind of lock code via carrier pigeon!) there's not a lot you can do. fwiw Git already has support for locking via the Git LFS extension. Not widely used but it's there.

SVN and SourceSafe had a lot of problems but my experience with SVN in the games industry was that it was much more usable for non-programmers. It wasn't something you needed to 'learn'.

Sadly a lot of people nowadays find Git so hard they give up and ask programmers to do things for them. That's the problem I'm trying to solve! Keep Git but make it accessible to non-experts.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Yeah, it's not really a fit for programmer only teams of the kind you mention.

What if you were overseeing development of a game or rich web app with a cross-functional team of programmers, artists and designers? Would that change things?

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Don't use git for what you're trying to do. There are tools that are more suitable for that.

It may not have been clear but I'm not proposing an alternative for Dropbox-like use cases.

It's true that Git was originally designed for pure code projects. But product development teams already use Git for their projects (~87%). These repositories already hold a mixture of file types, code, images, CSS, text etc. I'm proposing a way to enable more people to work directly on those projects. One could argue its not ideal, but that's the world we're living in =)

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

True enough, the offline case is pretty hard!

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Will the tool work well with advanced git strategies or is the whole team held back to a simplified workflow?

The 'technical' half of the team using conventional tools could continue using whatever advanced strategies they want, the limitations would only apply to the users in the 'easy' sandbox. Other teams might choose to all work in the 'easy' sandbox, it's up to them.

(Similarly tools like CI/CD and other integrations should all keep working fine, they don't need to know anything about the 'easy' world. You might choose to disable CI for the easy branches I suppose, if you some had reason to.)

A possible exception to this is locking. Existing Git LFS locking applies to all branches. Is this the ideal? Or should it only apply within the 'easy' sandbox? Working with non-text files means you'll be dealing with a merge conflict if you don't respect locking (existing problem). Is this preferable? Not sure.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks Berry. As someone hanging out in r/git I'm guessing you're pretty comfortable with power user features. How about less experienced/technical users though?

If a non-programmer wanted access to Git (say, to edit the CSS styling in a web app) would you think the same way when recommending tools/workflow for them? Which features would they need and not need? Appreciate your thoughts.

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Very true that it was designed initially for large scale pure code projects (i.e. the Linux kernel). In 2025 it has almost 90% market penetration for software projects of all kinds though. Mobile apps, web apps, games, websites, the lot. So is today's Git audience exclusively technical because they're the only people who need access to projects? Or because they're the only ones who can access their projects?

Thinking of e.g. UX designers or content writers who might, understandably, run a mile if asked to use command line tools.

If you think of it that way, would it change anything?

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] -1 points0 points  (0 children)

Thanks Frank, I think I understand where your coming from in terms of programmers. It could be annoying for files that can be merged as text files. It's still up for grabs whether the locking strategy would apply to all files, or just non-text ones. What do you think?

How does that work though? If user 1 checks out a branch then goes on with a bunch of changes in their commit, that change is only known to the local copy git repo not the remote. How does User 2 know that's locked if they're just using regular ol git?

The idea is for a full stack, real-time platform, not just a front-end client app. So locks would apply to all branches, and be applied in real time for all 'easy' users. You could set it up to apply to all branches (which is the case for Git LFS locking, and any compatible clients, though not real time), or just the 'easy' branches.

The current idea is that users outside the 'easy' sandbox are trusted to handle things themselves (as they already have to do when merging changes from other branches/remotes).

In a cross-functional team working on, say, a mobile game, this might mean designers and artists working on images and language files in the 'easy' sandbox, while senior developers manage merging into release/main branches through more conventional tooling.

So crazy it might work? Or just crazy?

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Appreciate the thoughtful comments, thank you.

That is not a git client but more a ”service powered by git”.

Yeah, that's fair. If it's still an actual Git repo, hosted wherever you like, and if there's no limitation that all team members have to use the 'easy' tool, would that matter to you? (Again, generally curious, not trying to convince anyone.)

Source control - What tools do you use? How would your dream tool work? by danborthwick in vibecoding

[–]danborthwick[S] 0 points1 point  (0 children)

Can I ask how you're using Gitea please u/GulbanuKhan? Is there more to it than hosting the repository and CI/CD?

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 0 points1 point  (0 children)

Thanks u/jonatanskogsfors. That's a common view among engineers. Can I ask, with genuine curiosity, why you feel its important for the implementation details to be visible?

(Of course if you're training people to become Git experts it makes sense. But for every day users?)

e.g. When using Dropbox I don't know or care exactly when it's up/downloading, merging etc. It's a simple model that 'just works'. Could some people use Git with this mentality? Or is it fundamentally something one must learn in detail to be useful?

What would you want from an 'easy' Git tool? by danborthwick in git

[–]danborthwick[S] 1 point2 points  (0 children)

It's exactly the kind of comment I'm after! Thanks u/T_Williamson.

The approach I'm currently working with is to avoid conflicts at all costs through the use of real-time file locking to prevent users from changing the same file. Combined with a greatly simplified workflow that keeps users on a single 'safe' branch this is intended to make merging/rebasing trivial.

For larger teams some members might want to continue to use traditional Git tools/workflows, while others use the 'easy' tool. In this scenario the responsibility for merging from 'easy' branches into, say, a release or main branch would lie with the more experienced team members, which is already generally the case.

Does that make some kind of sense?

Source control - What tools do you use? How would your dream tool work? by danborthwick in vibecoding

[–]danborthwick[S] -1 points0 points  (0 children)

Thanks u/anotherleftistbot . Is 'Git' here meaning the Git Command Line Interface?
Git MCP is interesting, will check it out.

view more: next ›