Git Miscellany: Stuff I Didn't Know But I Do Now

You don't need to be an expert in order to show someone else how to do something. There is a lot we can learn from experts, but there's also a lot we can learn from someone who is 2 steps ahead of us, like "Watch out for that step!"

As we found out yesterday in You Aren't Instantly Awesome, and That's Okay, I'm not afraid to share what I do know even when there's much, much more that I don't know.

Last week, I did an introduction to Git presentation for a user group in Las Vegas. I am by no means an expert, but I can share my experiences in getting started with the tool and what helped me get comfortable with it. And that's what I did: Getting Started with Git.

Of course some questions came up that I did not have the answer to. Well, now I do. That's what's really great about continuous learning. So let's take a look at those questions.

Commit GUIDs
In distributed and disconnected systems (especially), we end up using GUIDs (globally unique identifiers) to mark our items. This ensures that 2 people don't use the same identifier that then causes problems when we try to bring the records together.

Git has identifiers that look like GUIDs to mark the commits:

So the question came up: How are these identifiers generated?

After a little bit of searching, I found the answer: These aren't GUIDs; they are SHA-1 hashes of the commits.

The hash is used for data integrity of the Git repository. So the idea is that when we create a commit, that changeset is used to generate a hash value. This value can be checked to make sure that the repository has not been tampered with.

Since Git is distributed, that means that I have all the files for the repository on my machine. It's possible for me to go in and monkey with a changeset in the Git repository on the file system. But if I tried to push that or otherwise try to use that particular commit, I would end up getting an error instead. If you modify the files, then the hash of the modified files will no longer match the has that was generated with the original commit.

For a little more information, you can check out this article on Wikipedia: SHA-1 / Data Integrity.

The "-u" Parameter
When doing an initial push or pull with a remote repository, the sample commands show using the "-u" switch. Here's the instructions from GitHub for pushing a local repository to a newly-created GitHub repository:

The "push" command will push to "origin" (the name we gave to our remote repository location) from the "master" branch (our main branch on our local repository).

But what does the "-u" parameter do?

I found the answer to this in the Code School - Try Git tutorial that I mentioned in my first Git article. Specifically on Step 11: https://try.github.io/levels/1/challenges/11

This tell us that "-u" sets up a default for the push command. So the next time we need to push to the remote repository, we can just use "git push", and it will use "origin" and "master" automatically as the parameters.

The same is true when we use "git pull" and the "-u" parameter.

I highly recommend the Code School tutorial. When you go through it, be sure to check the "Advice" box next to the file system display. This has a lot of helpful hints.

These aren't necessary to completing the tutorials, but they are extremely helpful as we start to go a bit deeper. I actually missed these my first time through, and I found lots of good stuff when I went back to look.

Remote Repository Options
The last question is a bit more complex. I won't give a specific answer, but I'll show you where to find what you need.

How do I set up a remote repository on our company network?

There are a myriad of options for remote repositories. Two easy off-site hosts are GitHub and Visual Studio Online. But what if we want to set up our own remote repository on our server?

It turns out there are a lot of options for this. What you choose will depend your specific needs. And this is all spelled out in the Git "Book", specifically Chapter 4. Start by looking at Git on the Server - The Protocols.

What I like about this (even though I haven't had to do this myself) is that it gives Pros and Cons to using a particular protocol. Here's a snippet:

Then from there, the rest of Chapter 4 is all about the setup process. The complexity of the process depends on your needs -- from just having a network file share all the way up to a full-blown Git server.

Keep Learning; Don't Be Afraid to Share
There are certain topics that I am very comfortable with and have a lot of experience in. It's easy for me to share what I know with others because I've probably had the same questions that they do.

There are also topics that I'm still new to. It's a bit harder to share because I know that questions will come up that I can't answer, and I know that there will probably be someone in the room with much more experience than I do. (In fact, one of the attendees at the user group meeting had been using Git as their source control system at their company; he was nice enough to help out with some of the questions.)

But I'm not afraid to say "I don't know." And it usually turns into a blog article. Just like this one.

Even if you don't know everything, it's helpful when you say "Watch out for that step!" to the people behind you.

Happy Coding!