Also, if you have a Kindle reader, the GIT book is free - Pro GIT
Just like to add a piece of advice similar to this: if you’re using GitHub Desktop, close it while working on your project. It very often keeps files open/locked, and the IDE does not check for this when writing its files. I’ve had it happen many times where my changes weren’t written to disk because I had GitHub Desktop open. I’ve learned to only have it open as long as necessary.
I really wish the IDE would detect that it was unable to write some files during save.
What you should really be wishing for is GitHub Desktop to not be an Electron dumpster fire. It should not keep files open like that, but who cares about doing software right these days? I occasionally leave Versions.app open accidentally and have zero issues because, Mac! I haven’t left Fork open like that yet, but I would suspect it doesn’t cause the issue either.
I fully recommend Fork as a Git client. I intend to purchase it whenever it finalizes, provided it’s not SaaS for no reason.
SourceTree doesn’t have an issue with that either.
[quote=397210:@Tim Parnell]What you should really be wishing for is GitHub Desktop to not be an Electron dumpster fire. It should not keep files open like that, but who cares about doing software right these days? I occasionally leave Versions.app open accidentally and have zero issues because, Mac! I haven’t left Fork open like that yet, but I would suspect it doesn’t cause the issue either.
I fully recommend Fork as a Git client. I intend to purchase it whenever it finalizes, provided it’s not SaaS for no reason.[/quote]
The new version is. Version 224, the final “legacy” version, is not an Electron app. The choice of tool really has nothing to do with it keeping files open.
I hadn’t heard of Fork though. Looks nice, I’m going to give it a shot. I like GitHub Desktop because it integrates nicely with GitHub (duh) and packs a respectable number of features into a clean UI. And it’s free. It’s not perfect, especially now that it isn’t developed anymore, but it’s been my tool of choice since switching to Git.
Fork integrates with Github! 
Ive been using Tower for the last few years. They just switched to SaaS, but I still find nd it to be a solid solution.
SmartGit works well for me, as GUI to git
https://www.syntevo.com/smartgit/
Syntevo:
[quote]Non-Commercial Licenses
SmartGit can be used free of charge by Open Source developers, teachers and their students, or for hobby, non-paid usage. We are also supporting certain non-profit organizations like public welfare or charities. If in doubt, please contact sales.[/quote]
No matter which language or toolset you use you will always have manual work to do when you have to merge branches etc., once you are working on any major project with multiple developers. It is just a fact of life.
I’m surprised nobody mentioned SourceTree. I use it daily with Mercurial but it does work with Git.
Look up. 
Oops.
My team’s GUI of choice is Tower, but I also use SourceTree and (mainly) the command-line.
Our best practices with git and Xojo involve not having two developers working on the same class at the same time. The Xojo IDE tends to keep things in alphabetical order, which means that as soon as you refactor something its position might move in the file, not to mention some of the artifacts that keep getting added like random indentation or TabStops.
But keeping it one developer, one file (in essence treating it like a binary file) is the best we came up with.
Project-level conflicts are rarer since that file is typically just a list of other files, so if you have a conflict it’s easy to fix it or re-do the work (adding or removing classes) manually.
I’ll use this one soon. Many people prefers it over SourceTree.
https://www.youtube.com/watch?v=Lb4yvfrX_7I&list=PLe6EXFvnTV7-_41SpakZoTIYCgX4aMTdU
I am not one of those.
I’m being pushed away from MacOS day by day, so let me rephrase…
Many people prefers it over SourceTree; probably with more Windows people, and even more Linux people, as SourceTree isn’t even a Linux option. 
But I understand that for enterprise use with their own private servers it has costs and for some it’s a “no go”.
Sadly I have to admit, I feel like Rick. Not only moving slowly away from Mac as my main development platform to Debian. I’ve used Tower but since they moved to SaaS and collecting telemetry data, I’ve stopped using it. Sadly to say it’s the same with other tools I loved in the past like Paw. Today I can’t recommend any because everything in the Linux world is not really comparable with the comfort of Tower or with the UI on Mac. And Gitkraken is based on Javascript Electron, it’s not really native nor secure to me.
Well, this seems to be the price tag for Privacy and Data Sovereignty. I am writing this from my mid 2014 Retina Macbook Pro and it is the last Pro Macbook from Apple since the latest Generation is struggeling with thermal issues, keyboards, not removeable SSD (a no go for some clients of mine) and many more… I’ve not mentioned the connectivity and adoptors yet… but this is another sad topic…
That’s why we didn’t go the Git way, but chose Subversion. In Subversion we tell the files that they need a lock. Then when a developer wants to work on a piece of code (for instance a class) he needs to lock that file. When a file is locked another dev can’t work on it at the same time, since it’s locked. When commiting the changes, we unlock the file again, making it available for other devs.
We used the xml project format with external files so that they can be shared between projects.
I know the question was about Git, but I just wanted to pipe up because the problems described is why we didn’t go with Git.
Hey guys,
thank you so much for your input!!!
we took the time to compare a lot of git clients during the last days.
It turned out, that the perfect solution for us is the following:
- As GUI client we use GitHb Desktop. It’s easy and lightweight and it has all the stuff we need. The console is fast opened, if you also want to do some terminal git commands. Also the one-click-checkout is easy to use if you are aware, that this changes your branch code immeditaly.
- Our Git hoster, GitLab is one of the best services I experienced from a business tool. We use their in-build merge request feature, which merges the different branches without any distraction or diff problems.
- We switched our branch usage from developer branches to feature branches. So we now have a lot of branches open (for every feature we’re working on), but the code changes are smaller. Merges getting easier since this.
- I’ve set up a workflow, which saves a codebase before pushing to a custom folder on my mac, just in case some code is lost after pushing or merging, what we experienced during the last weeks.