next »

[oodavid]

At the risk thoroughly exposing myself as the newb I am, can anybody recommend a good GUI for Git? I've taken a look at the Git Wiki and it appears I'm spoiled for choice!

https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces

Conscious I'm branching (forking?) us into a more specific topic, so it might warrant its own thread.

Don't bother with a GUI and just use the shell. Lots of advantages for the shell, for one it's the same on any OS / machine. Don't worry about the plethora of commands, at first you'll only use a handful:

Git add
Git status
Git diff
Git commit
Git log
Git push
Git stash

I think this its perfectly on topic, for a developer version control is one of the finest tools you have.

[Jonathan Burroughs]

I guess coming from a big game development background I'm used to using a solution like Perforce or AlienBrain to store the entire project, including audio and art source assets. And as such having a user-friendly GUI has been helpful when you're collaborating with people less accustomed to using text commands and specific syntax. Typically artists, animators and audio engineers. But, I guess that's less applicable on a small indie project. There's a learning curve for me there.

[oodavid]

My only issue with a GUI is that they're someone else's visual abstraction of Git and the features of Git. That is to say, they're always going to be at best one-step behind the command-line*, and at worst a severely limited subset.

Take a look at the Summary (feature matrix) and you'll have to compromise on features that you don't yet understand, ie:

• 40% have a tree view (and another 10% with arbitrary or partial trees)
• 30% have history searching
• 30% have unstaging (an "undo" feature for one particular process)
• 30% have cherry-picking
• ...and so it goes on

All of the features are super-easy to do with the command line AND you can create custom shortcuts for anything you want.

IMO the best approach is to get accustomed to the shell, then fall back to a GUI for any "fancy" features.



* apart from gitk and git-gui that are distributed with git.

[apookapus]

My only issue with a GUI is that they're someone else's visual abstraction of Git and the features of Git. That is to say, they're always going to be at best one-step behind the command-line*, and at worst a severely limited subset.

And as an added bonus, if you learn the command line you can always fall back to it even if you prefer a gui client. Being able to move your knowledge into an environment where the gui isn't available is valuable.

[apookapus]

A person could also use CVS.  It's not like it has stopped working.  But why would you want to?  If I was a person coming to version control, with no prior knowledge, and no legacy systems tying me down, why would I choose the older, less capable system?  And it is obsolete.  By definition, newer, better things exist, making it obsolete.

The choice of version control is so much less important than the fact that you use one.

A religious war about the perceived superiority of git over svn doesn't have much value. If you can get your code into and out of the repository and trust that it's safe there, have the ability to diff and branch, then let your requirements dictate everything else. They're all similar enough that once you're familiar with the basic operations, you can get up to speed on any of the others in an afternoon of tooling around.

[Garthy]

Re GUI versus console, personally I prefer to take the best of both worlds: Learn both and use the best features of each. Repetitive tasks tend to work better on the commandline, and visual diffs tend to be vastly superior to text-based ones. Also, GUI learning curves tend to be lower.

For example, personally, I use the Subversion commandline either directly or in scripts most of the time under Linux, but use the visual tools a bit more under Windows. On both I use visual diffs (Meld for Linux, TortoiseSVN for Windows). I'd hate to be stuck with console-only or GUI-only. Use both.

As for which GUI to use, whilst not familiar with Git GUIs, I did notice TortoiseGit. TortoiseGit appears a port of TortoiseSVN, and I have used TortoiseSVN. TortoiseSVN is a fine tool- inbuilt visual diffs, and it highlights files in the explorer with their status (eg. if you've modified them since last checkin). Probably a bunch of other features too, but they're the highlights for me. I suspect TortoiseGit would be worth a look for this reason. There might be better options though- take someone's direct experience over my indirect experience!

[ThemsAllTook]

A person could also use CVS.  It's not like it has stopped working.  But why would you want to?  If I was a person coming to version control, with no prior knowledge, and no legacy systems tying me down, why would I choose the older, less capable system?  And it is obsolete.  By definition, newer, better things exist, making it obsolete.

The important thing is that git and svn don't occupy the same space, while svn and CVS do. If you want a distributed system, git is probably your best choice. If you don't, svn is still great.

[Bandreus]

The choice of version control is so much less important than the fact that you use one.

This.

Just pick the one which seems like the best to you. Learning your way into various source control systems is not at all that hard.

So yeah. If you happen to not like Git (or whatever system you opt to use) you can simply use a different system for your next project, no biggy.

Also, as already pointed out, use of a GUI doesn't rule out being able to dish out the shell in times of need. I completelly second your sentiment about usability concerns for less technical-oriented people in the team. Just pick a GUI wich is nice, simple to use and which offers an adequate amount of features.

Sadly I have no prior experience with Git GUIs (mainly shell guy here).

[bateleur]

Quick tip regarding version control: Make sure at least one of your backup measures does not involve version control.

For all its many upsides, the big problem with version control is human error. In thirty years of programming I have frequently and consistently heard developers complaining about losing data or having to undertake incredibly complex rescue procedures due to version control errors. Much as it's not very sexy, just take a copy of your entire development folder every so often. It's easy to do, virtually free and one day it may save you from disaster.

(Most of the upsides to version control, incidentally, have nothing to do with backup. Anyone only using it for backup is largely missing the point.)

[WildFactor]

Quick tip regarding version control: Make sure at least one of your backup measures does not involve version control.

For all its many upsides, the big problem with version control is human error. In thirty years of programming I have frequently and consistently heard developers complaining about losing data or having to undertake incredibly complex rescue procedures due to version control errors. Much as it's not very sexy, just take a copy of your entire development folder every so often. It's easy to do, virtually free and one day it may save you from disaster.

(Most of the upsides to version control, incidentally, have nothing to do with backup. Anyone only using it for backup is largely missing the point.)

Good advice. But it's probably good only when you are alone working on a project.
If you are a team of 10 or 50, everybody have an almost up-to-date version of the entire project on his hard drive.

But I have myslef a versionning + online backup system (crash plan).

[Jonathan Burroughs]

Something I'm not accustomed to is separating out version control of code and data. When I worked in big studios we typically had a Perforce depot which contained the entire project, including design documentation, source art and sound assets, builds, everything.

At the stage we're at in my project right now we're iterating a lot on content; environment art, animation, audio, but not so much on the game systems and logic. My concern is that our workflow for keeping our level designer, artist and composer in sync is a little flakey to say the least.

Do you guys have any advice for version control best practice where you keep an entire project synchronised between all collaborators? Or is that just excessive madness?

[Pockets]

So what is it you're doing at the moment?

I've never had any issues with the "perforce for everything" approach; one depot, assets in their own directory tree, labels to keep everything organised. There's probably fancier solutions to the problem, but that's always been a reasonable balance between simple and organised for me.

Having said that, that's not really from any working remotely, just from the day job and solo stuff evenings and weekends.

[Jonathan Burroughs]

Right now we're periodically uploading the project to Dropbox and trading assets on an ad hoc basis. It's horrid. And massively error prone.

I've just come across this:

http://makegamessa.com/discussion/811/tutorial-version-control-in-unity-using-mercurial-source-tree-and-bitbucket/p1

I suspect tomorrow my life is going to change forever.

[Pockets]

Ouch. That guide looks handy, good luck with it.

[nikki]

you can put all your resources in git no problemo (well size might be one eventually )

your teammembers and you then just do:
'git pull' to get the latest freshest stuff
and when your done adding/iterating and have something to commit you do a 'git commit -m 'and some message''
rinse and repeat.
when you want to put all you've done in the remote repository you just do 'git push'

I would advice against a gui thing for git at first, just play with it on the terminal and make some test repositories

[Jonathan Burroughs]

Ah! I think this was an unhelpful conceptual block I had created for myself. I assumed, seemingly quite incorrectly, that Git was only for hosting code. And that a separate solution would be needed for hosting big files. If I can keep my entire project within the upload restrictions of Bitbucket then perhaps I'm golden.

nikki, I'll absolutely do as you suggest and experiment with some test repositories before getting bogged down in GUIs.

[Jonathan Burroughs]

Actually since posting that link I've kind of swung back to favouring Perforce, particularly since discovering their 20 user free license:

http://www.perforce.com/downloads/Perforce/20-User

It's what I know. And it seems best equipped to deal with a multi-gigabyte project like the one we're currently running. I'm a little uncertain about how to set up the server in a way which is best for collaboration. I have an old desktop lying around which I might stick Ubuntu on and use that to host the server, rather than having everything live on my local machine.

[Ky.]

I store absolutely everything on a private GitLab server with occasionally sync to a private BitBucket.

I don't even care if it's a code based project, every single thing i do (Documents, audio, photo albums, just about everything), ever, is managed by Git and Remote VPS storage

[Rusk]

I store absolutely everything on a private GitLab server with occasionally sync to a private BitBucket.

I don't even care if it's a code based project, every single thing i do (Documents, audio, photo albums, just about everything), ever, is managed by Git and Remote VPS storage

It would be an ideal solution if VPS storage wasn't so expensive. You can get 15 to 20 GB for next to nothing, and then it seems the price scales exponentially. Or have you found a good deal somewhere?