The thing that makes git confusing is that there are lots of different possible work-flows. This is not a bad thing, but it does make it harder to learn.
As an example, think about writing a forum post - and here I am talking about the very low level, the actual process of typing a sequence of characters in the right order. Just think about all the different ways you can do that. Do you just type perfectly, and never have to correct that? Or do you often make mistakes, and have to go back and edit? When you have to edit, how do you do it? Do you just delete backwards until you have got back to the last character and retype, or do you move the insertion point back there to edit? When you move the insertion point, do you click with the mouse or do you use the arrow keys, or do you choose depending on where you have to move to? and so on. Imagine having to write detailed instructions for editing text
Anyway, the reason that is not a problem for editing text is that you can clearly see the current sequence of characters on screen, and you know what sequence of characters you would like, so you can use you favourite methods for editing text to get to where you want to be.
Anyway, git is flexible in a similar way. It is a tool for managing sequences of versions of software, rather than characters, and there are various ways you can edit things one step at a time. Perhaps, rather than thinking about particular workflows (how you edit), it is better to focus on "how do you see the current situation?" and "what situation do you want to be in?".
To see the current situation, I find the tool gitk to be the best. It gives you a graphical view of all the versions you have got. It can take a while to get the hang of what it is showing you, particularly since Moodle is being actively developed, and so you have about 100 new versions every week. (Typically with very small changes between each.) Other ways to see what is going on are the commands 'git status', 'git branch' and 'git log'.
The situation you want, when you have customisations, probably looks like this: You have a given, the MOODLE_24_STABLE branch (or whichever branch you are following). Then you have your version of the code, which is that version, plus a few changes. The best thing is to commit your changes to git on another branch, for example called MYMOODLE.
So, to start off, you create your branch starting from the standard branch:
git checkout --track MYMOODLE MOODLE_24_STABLE
then you make some change, and then you commit them to your branch, which you coudl do with
git commit -a -m "Hack around with feature X."
You may repeat this several times, as you make different customisations.
Then, at some point you will want to update to the the latest versoin on the Moodle 2.4 stable branch. You do that with the command
As with a CVS update, you may get merge conflicts at that point, in which case you will have to solve them manually.
From time to time it is worth reading the documentation about the commands you use frequenty, to try to understand what they are rearlly doing. Also, it is a good idea to keep the gitk window open while you do things, and refresh it frequently, so you can see what effect your commands are having. Sugested documentation: