due to the distributed nature of git - what is a big win for real developers (but not so big for spare-time users like you) the whole process
of bringing a code change into a repo is splitted into 4 parts
1. change the code
2. stage the code you want to commit
3. commit the code
4. push the code (if you want to and if there is a configured remote repo)
the worksflow seems a bit huge but i can tell you that it is a big win
same goes to pulling, fetching etc. variant how to update your repo - only needed if there is a remote repo configure (that is not needed at all)
pull grabs the changes from another repo and tries to merge that into your current work - you should stash(not stage) before (some sort of clipboard) if you
know that there are conflicting changes in the other repo (the other developer told you before, or git is telling you)
fetch just grabs the new content and leave it to you when to integrate that new stuff in you current work (think of pulling the lastes 12000 changes from the linux kernel repo, grab you laptop and go on vacation without network - you then can integrate that stuff a later time - integrating 12000 changes could take hours (or minutes) if there are conflicts you need to solve etc.)
a remote repo could be bitbucket or github, but can also be just another local repo in your (network)file-system (there is no need for a server or over-network stuff - its an option)
so the main git features are:
branching and branch merging
pulling and merging
stashing before merge or just to lift away your changes for a short time
staging for making changes ready to commit
pushing (for updating other remote repos)
but the benefit for a some lines changing 2 man project is not that super-huge - but having a reverseable commit history is always a win - even if some developers don'
t understand that because they only work on trivial 15 line programs

im working currently with 12 developers on the same 230.000 lines project - would be very hard to do without version control, or with 43 developers on a 1.000.000 lines project - which is impossible to handle without
its typical for large development to have serveral branches open for feature-development and serveral developers working combined on some of these branches - sometimes in the same files - which produces conflicts on commit/push, but git is helping to prevent any loss and help to keep such projects under control
for example: i've changed 147 files the day before conflicting with 4 other developers work
another example: i've worked for a company with a usa, india and german development department, >150 developers, with a source change push (with 1-30 files) to the main repo every minute from people around the world - its nearly impossible to manage such code evolving without something like git