BIGGEST AHA MOMENT HOW TO
BIGGEST AHA MOMENT CODE

In the past, I would often stash the local changes. Sometimes I work on a branch b with local changes, and I need to check out another branch and do some work there. Committed changes can be reset to local changes again. It is very liberating to know that almost anything I do with git can be easily reverted, undone or redone.Ħ. Now I can simply do the merge again, and hopefully resolve the conflicts correctly this time. As long as I did not push to the server, it is no problem to go back by doing a “git reset –hard HEAD~”. For example, if I merge some changes, and I mess up resolving the merge conflicts, I can simply go back one step and do it again. In git, I took me a while to realize that the same functionality exists, but it is not defined explicitly. When I used svn, I often used –dry-run to see what would happen if I did a certain operation (but without actually doing it). Merging master into b at regular intervals means that when I finally merge b into master, most of the merge conflicts will already have been dealt with.ĥ.

It was a big conceptual aha moment for me when I realized that I don’t have to wait till b is done before I resolve some merge conflicts. Eventually I want to merge all the changes from b into master, but that can only be done when b works as intended. If you have a long-running branch b that you eventually want to merge back into master, you can resolve the merge conflicts a bit at a time by periodically merging master into b (and fix any merge conflicts that arise). Now of course I understand that it is important to see at what point commits from another branch were made reachable by a merge.Ĥ.

BIGGEST AHA MOMENT CODE

Often they are empty, with no code diff at all. I viewed commits only as “what is the diff of the code for this commit”, and from that perspective, merge commits didn’t make any sense. Since my understanding of merging was incomplete, merge commits used to be a bit of a mystery to me. Showing a diff between two commits (adjacent in time, but on two different branches) can give a really big diff.ģ.

For example, showing git log of a file (for example in P圜harm) can show commits from two different branches interleaved. Realizing that commits from a branch remain, and that merging simply allows them to “be seen” in the other branch helped explain some odd things. Initially my mental model of a merge was that all changes from the merged branch became commits at the time of the merge. It took me a long time to realize that merging simply makes already existing commits accessible. This concept of there being two independent sets of changes – local changes, and changes on the server (pushed there by other people) – took me a while to really grok.Ģ. But to see the changes on the server, I first need to do a git fetch. You can run git status, and that will show the local changes compared to what was last pulled. In the beginning I was confused about the equivalent operation in git. I often used “svn status -u” to see what changes I would get if I ran svn update. Local and remote changes are independent. But I remember literally thinking “aha” when I understood a concept and realized the ways in which I could then use git.ġ. Looking at these aha moments now, they all feel really obvious.

BIGGEST AHA MOMENT HOW TO

Here are six big “aha moments” I had on how to use git. I read a lot on how git works, but even so, I didn’t always realize what the implications were for how to use git. Even though I am a pretty quick learner, it took me a quite a while to really understand git. When I switched jobs four years ago, I went from using subversion (svn) to using git as the version control system.

Biggest aha moment