This Friday (3.02.2017) I was lucky enough to go to Git Merge in Brussels. It was a lovely conference! However, just a few months ago I would not imagine going to a git conference, or liking anything related to version control.
Like many new developers I was aware of git and was using it, without really knowing its depths and capabilities. Now I can ate least do git rebase -i or git merge branch-name fully expecting what happens next. I also have learnt that the only difference between a person who is fluent with git and a person who isn't is the fact that former actually has done those things before.
While reading Code Complete I stumbled upon an explanation of why this may be so. This is a quote from Chapter 2, which talks about importance of metaphor for learning and understanding complex concepts.
Software development is a younger field than most other sciences. Itâs not yet mature enough to have a set of standard metaphors. Consequently, it has a profusion of complementary and conflicting metaphors.
I believe version control is in many ways an example of that. Think about rich metaphoric content: there are trees and branches, commits are like berries that can be picked (even cherry-picked) and squashed, branches and commits can be merged like rivers and rebased like a stack of objects, changes can be stashed and poped... This is getting more confusing by the second. After actually doing all of those things concepts are settling in the brain, but there is no easy analogy, no entry point for a complete beginner to grasp the entire idea.
That's why I was really glad to see a talk by Santiago Perez De Rosso on this topic. He talked about how git is badly constructed form conceptual standpoint, and how many objectively experienced developers still lack confidence when using this git.
If you are a beginner with git, it may feel overwhelming. I am here to remind you: it's not you, it's git. Many people feel or have felt the same way. You are not alone. Here I've made a short list of things that people who are in need of git support right now may find useful.
In case you are a visual learner learngitbranching is really helpful and beautiful. It is however much cleaner than real life, so keep in mind that in collaborative coding resolving conflicts is going to happen and it is really not that scary (after the first time).
Try Git by GitHub is a short intro, with helpful repo visualisation. Naturally, there are docs and a book for more thorough study. Be warned that this is not the most exciting read, but will definitely answer your questions.
Delightful Oh, shit, git! (by most compassionate Katie Sylor-Miller) is there for you if the bad thing has already happened. In my experience it really covers all the bases from simple git reset HEAD^ to nuclear rm -r fucking-git-repo-dir. Git tag on stackoverflow is there for the rest. And unlike many other problems in programming, git ones are rarely unique. The problem you have was very likely solved about million times before by two bash commands.
Gitless
is a solution which will completely remove the need to understand git. Instead it offers an alternative that is easier to use (by previously mentioned Santiago Perez De Rosso). One can always rely on git in case of troubles, but has to avoid mixed metaphors in the day to day pushing (gl publish) and pulling (gl fuse).
Most importantly always remember, that git is there so you can make mistakes. At any moment in time you can give up and pretend nothing happened by reseting to some previous state. Remind yourself about that next time you hit an existential crisis!
