Too Git To Quit

I am not currently a Git master. I may never truly master it but I do know that learning it has been an overall enjoyable experience. It didn't start off that way though! In the beginning, it was complicated and honestly fairly confusing. I didn't understand it and because I didn't understand it my brain was telling me to try to get through it as quickly as possible. I noticed that something as simple as remembering a certain command was hard to remember because I was afraid to mess something up because the lack of knowledge scared me. So I used that as leverage and reversed the way I was thinking. I started thinking that I can't break anything that I can't technically rebuild from the ground up. So I lost the fear and started learning!

I learned in an order that worked for my task at hand. I just needed to use Git and Jekyll so that I could simply push updates from a local host to a live site(Github Pages). Once I started looking at the commands as jobs or functions then it helped me understand that the various commands had a structure or particular order. Chris Peak truly helped me with this by giving me a few pointers on ways to speed up the process of this. For instance using the terminal, and using the up and down arrows can filter through past commands that have been used. The first time I pushed my local files to Github and it actually worked I still didn't understand what I was even doing. I knew that if “I typed this then that it would do this” type of thing. So the first time that I pushed something local and it didn't work, I truly had no understanding of why. Heck, I didn't even really know what to search for in order to find a solution or reason to why it wasn't working in the first place. Thankfully, after that moment, is where my mindset started switching!

I knew that I could start over which gave me much more confidence in starting to learn. Since I currently am not working with a team to review changes, a pull request command seemed like something that I could push off for a tad bit. I decided to start with the add command first. I knew I had changes ready so it made sense that I needed to tell Git that I would like them added. I then used “git status” to verify that the files that I updated were recognized as modified files. This helped me understand the flow within Git. Any time I saved files, I could check the status to see that a file was recognized as modified. Using “git add” simply helps stage the files and helps let people know that these files are ready to be moved to the next step.

That next step for my process was learning to use “git commit -m”. This command basically allows us to save and also track changes in the code. Something I didn't do early on but I am improving each time is writing a good commit message that describes what my changes actually solved. I would always write the same message early on but now that I understand it more, I see the value in writing a message that isn't vague. This isn't good for personal use nor would it be good in a team setting. To better understand how I could improve on my own messages I used “git log” to view old commit messages. My basic messages would make it hard for me to know what changes I made. For now on, I'll make my messages slightly longer but they will be more specific to the changes committed so that they will be easier to understand. As an example my old message might have been “added margin” future changes will be something like “Added margin to nav items to prevent them from overlapping logo”

After committing changes I move forward to “commit push” commands. The push command is what takes my local files to my Github repository. So it goes from my computer directly to the main branch of my website all within seconds. Now is the best time for me to talk about a pull request because it took me to understand the basic functionality of the previous commands to understand why a pull request would be important. Pull request on Github gives a list of all the modified, added or deleted files. You have one final place to review changes. This also allows a single user to be their own code reviewer.

I'm sure there are things that I will constantly learn from here on out. Like my code, I'm sure I'll make subtle changes to my workflow on Github. My goal is to learn as much as possible without the fear of breaking something along the way. I can always use Git commands to find mistakes or problem areas to help find issues, it will just be up to me on how easily I make it for myself.