Learning Git the Hard Way: Part 3
Previously, in Part 2, we went over Git Branches and the HEAD. Let’s continue by starting off with Remotes and how to get your stuff to other developers or into a project.
Ryan Hanson
Learning Git the Hard Way: Part 1
There are tons of tutorials out there that show how to use Git, starting with easy things like cloning a repository and committing locally, then pushing your commit to the server. There are lots of sites and videos that will help you achieve a competent level of Git expertise – like this one. However, you may struggle with the interface and if you have problems, you may struggle to understand why and how to fix them. That is why I am going to explain Git this way: inside out, backwards and hard. This three part series is targeted for people who want to excel at using Git and deeply understand it. This is also intended for people who are willing to persevere a bit more than the average person. Lastly, this is for people who like to see the beauty in things and, trust me, Git is beautiful.
Configuring Your Compiler
In my previous blog post about the C Tool Chain, I mentioned a post about configuring the C compiler, which is what this blog will discuss. Please note that I will not be talking about linkers or linking, just compiling.
Understanding the C Tool Chain
I find that in today’s age of IDEs like Visual Studio, Eclipse, Code Blocks, etc., that many developers get hung up on linker issues. This is completely understandable as many languages have moved away from the compiler/linker paradigm toward single compilation units or virtual machine code. Also, these modern development environments hide many of the steps that it takes to get a working executable out of working code. The result is that most of the C developers I run into are very familiar and are even experts in the C language itself, but unexpectedly struggle when presented with a build configuration issue.
Optimizing Code for Development Time
A while back I made an interesting personal discovery, and I want to share it with everyone in the hopes that it’s as useful to you as it is to me. Hi, my name is Ryan, and I like to develop software in my free time. Mostly, I like developing games.
It all started when I recently looked back over some of the work I did before I went to college. I was actually very impressed with my past work, too impressed. The games I developed before school were really putting my current work to shame. I started to think about why that might be. I figured I was busier now that I have marketable skills and, let’s be honest here, you can never play enough Dwarf Fortress.
