THINGS I’VE WORKED ON/COMPLETED…
- A Deeper Look at Git
- Working with Remotes - almost finished…I’m going to take my time going throug the last section instead of rushing to include in this week’s post(!)
ISSUES I HAD…
A DEEPER LOOK AT GIT
The order of commits in GitLens Interactive Rebase - I had some trouble with this, as it went from oldest to newest, which was particularly troublesome when it came to squashing commits as they need to be in a specific order in order to squash correctly.
N.B. I think other people will run into this next problem, so the information here may be useful! The rebase editor made it impossible for me to change the order of the commits so I Googled it and came up with a solution to use the Nano editor instead - this was the only way I could do it.
I continued to look for an answer to this though as I don’t think we were supposed to be using Nano and I found that this ("workbench.editorAssociations": { "git-rebase-todo": "default”} ) could be added to settings.json in order to “Disable VSCode Git Rebase UI” - that gave me an editable interface to work with (below), with the commits in the necessary order.
So even though I have obviously used some Git commands in the past (having been told to or just by following what I read after a Google search) - I actually found this section a bit tricky as there are lot of little things going on and you really need a good understanding of the differeneces between HEAD and Branch (which I thought I knew previously). Not sure if my brain was tired or if it just is tricky, but I just read and tried to Google things I didn’t understand until I had an ‘acceptable level of understanding’ as it’s another one of those areas that hopefully will improve for me as I use it more and in practice.
However, before moving on, I made a note of some of the key terms and tried to make sure I had a ‘pretty good’ understanding of their implications in terms of HEAD, the Staging area and the working directory.
WORKING WITH REMOTES
N.B. If you were confused by the ‘Reachability’ section in the ‘Think like (a) Git’ link in the assignment, you’re not alone(!). I was totally confused by the direction of arrows:
I had to Google this to figure it out. I could not understand how, if you started from ‘E”, the history would be A,B,C,D,E. So this is what I found out after Googling and please feel free to correct me if I’m wrong:
I was conflating the directionality of the arrows (in which way they ‘flow’) with what they actually represent, which is the Parent-Child relationship between COMMITS (parent pointing to child). Also, when it says ‘IF YOU START FROM E’ what it means is, if you are currently on commit E and you run Git Log, the git commit history you will see is A,B,C,D,E. Perhaps that was obvious to some out there, but to me it wasn’t since I had just come from reading about 'directionality’ in the previous section, so pointing this out this may possibly help someone.
THINK LIKE A GIT
I tried to use Git Cola as a GUI to help me with the practical exercises butthere were display issues even after troubleshooting do I decided to just try to do it in the terminal.
N.B. I’m not sure if it was how the material was presented, but I somehow intially thought that the Scout and Savepoint patterns were two different alternatives, but they are not(!). The are two different steps in the same workflow.
THINGS THAT WENT WELL…
Even though I still have a lot to learn, I actually kind of enjoyed learning a bit more about Git and I am glad I ‘made myself’ learn how to read commit history from the Terminal as I am sure this will prove to be useful.
THINGS I’VE LEARNT/NEED TO IMPROVE ON…
A DEEPER LOOK AT GIT
Git needs thinking about and things can easily ‘go wrong’ if you don’t understand what you’re doing, especially when collaborating with others.
If I remember nothing else, I will (try to) remember this paragraph:
If you look back through this lesson you’ll see a common thread. commit --amend, rebase, reset, push --force are all especially dangerous when you’re collaborating with others. These commands can destroy work your coworkers have created(!)
…and I think it’s worth noting this especially:
THINK LIKE A GIT
The ‘Think like (a) Git’ website can be (very summarised) by the words ’REFERENCES MAKE COMMITS REACHABLE’.
Branches acts as ‘safe points’ you can return to if your experiments (merges, rebases, etc.) go wrong - no need to back up entire working directories(!).
As I was having some trouble using a GUI for Git, I tried to learn how to read the Git output from the terminal using the command:
git log --graph --oneline --all --decorate
It’s very likely that I would struggle to interpret the output in complicated file set-ups, but I am satisfied for now that I understand the basic layout and symbols well enough to understand what’s going on - at least enough to serve me at this point of the course. I am actually very glad that I took the time to try to figure this out as it’s another one of those things that looks confusing at first, but after having figured some of it out, it instills confidence in what you’re doing.
OTHER…
n/a
PLAN FOR THE UPCOMING WEEK…
Finish ‘Working with Remotes’.
Finish ‘Git in the Real World’.
Hopefully start ‘Testing Basics’.
Top comments (0)