Tutorials for Beginners
There are great tutorials (video and text) that can help you start from a very basic level. Git seems to have a great approach to introducing the topic in a gentle way for beginners that tells you the why first and uses repetition, definition, and graphics to help you remember the names and functions of key commands.
SVN intended to be CVS done better. CVS (concurrent Version System) worked on things a file at a time, SVN typically worked on things a directory or directory tree at a time. SVN (and CVS or other systems) may be important if you are using it at work, but my opinion is that we significantly improve our understanding of what it takes to do source control every few years, so just as you would prefer a late model computer, you should prefer a late model source control tool. It is a huge investment to change systems, and code history can be lost, although for many systems there are converters that let you migrate your code as well as history and other artifacts created by the system being retired.
Professional Source Control Meets Professional Needs
Your question "How do professional use tools like GIT and Subversion to fulfill their project's needs?" closely relates to the question "How do teams work together without getting in each others way while still working as quickly as possible?"
The code is changing frequently with some developers making code that other developers will use, and with a variety of stakeholders needing differing levels of stability vs. innovation. Source control systems help by storing code for use by the team, keeping each change in context with versions that change with time and often also with branches that are controlled copies of the code that serve to isolate groups of changes from other groups of changes.
Bringing things back together, merging the work of many team members is a chore that in SVN and older systems was centralized and difficult. For teams using Git, merging becomes simpler and more accessible to the influence of the whole team instead of a few experts. In SVN, branching could be a personal matter, but merging often had painful impacts on the team and the movement of code back into the main line could be painful from the perspective of getting permission, avoiding breakage, and the level of effort needed the task.
From an established source control repository, professionals can fulfill other needs like diagnosing problems to their root cause. If there were versions of the code that used to work, and newly found problems that occur in the current version, it is possible to step forward and backward across the history to pin-point when the problem occurred. In SVN, this capability is immature, but in Git the search for the last working / first failing version is supported by a command called git bisect. The problem will be caused by one of the source changes between the two versions which is potentially a much easier diagnosis than a search of the entire code base.
Sorry to ramble, hope this helps you on your way toward using source control.