We are a .NET, Java and Rails store.
We used Subversion for many years and its fantastic system, did everything that we thought we needed from SCM. About 9 months ago, we started playing with Github.com, developing a Rails application (an inevitable part of the Rails community).
Since then, we have completely migrated to Github.com using private repositories for our commercial, closed source software development.
Git made us not interrupt the build or clobber code for months - something that happened from time to time, and made us lose work a day trying to fix the problem. Subversion does not provide you with the flexibility in your working methods that Git does. If you have problems (broken build or fix), Subversion will not help you, it will even work against you. Its branch / merge mechanism is very difficult to use because it does not track the origin of the branch. In addition, when you merge, the change history changes so that all team changes in a particular branch are attributed to the user performing the merge. Git is also lightning fast, since the entire repo you work in is local, which is very noticeable when you work in remote places.
However, Subversion will take you a week or two to get comfortable, Git takes at least a month, especially if you come from Subversion or CVS. If you pretend it's just a more modern SVN or CVS, you will be disappointed by the lack of improvement in the coding workflow, and you will be annoyed by the many commands.
We have an installation with three branches: fix ↔ master ↔ development. Under normal circumstances, the development team will work in the development industry. For each user story, the developer will create a development branch: user development history. When the story is completed, the user story merges with the development, and the user history thread can be deleted. This goes on and on, and the wizard remains stable and unaffected until the build manager decides that he will save all development changes back to the wizard. If at the same time the client calls and requires correction, this is also done in isolation from the main one and can be combined with the rest of the code base (master & development) at an appropriate time in the future.
Now refer to the GUI and SCM. We avoid them like the plague. Graphical interfaces are poorly suited for working with SCM. I know - controversial, but listen to me. The command line will slow you down more than the GUI does, and when you work with SCM, and there is a chance that you are going to do something bad or destructive for your central repo, slow is good. Slowly makes you think about your actions. All the typical graphical interfaces that I have seen (EclipseSVN, TortoiseGit / SVN) all pre-select your recent changes as part of the command that you are about to make, regardless of whether these changes are ready to be made or not. BADLY!!!! You need to think about your commits and how complex or complex they are - command lines work better than the GUI in this regard. All our .NET encoders, which, of course, access tasks using graphical interfaces, use the Git command line and use the SVN command line before that, only for the reasons stated above. This gave them a greater sense of control.