Basic GIT Tracking for Day-to-Day Work

[00:00:01.530] - Liz Fraley

In the T.C. Dojo open session today, we have Karl "Klash" Klashinsky. I've known Klash a good number of years now, in fact, he was my introduction to GIT when he was explaining some fine point about the difference with SVN and the benefits thereof over poker one night. In his spare time--does anyone really have spare time?--Klash is a rugby enthusiast, even traveling with professional teams as far away as New Zealand.

[00:00:23.400] - Liz Fraley

Have I got that right, Klash?

[00:00:27.130] - Karl Klashinsky

Yeah, you did.

[00:00:28.160] - Liz Fraley

All right,

[00:00:30.540] - Karl Klashinsky

Boy, your memory's good.

[00:00:30.690] - Liz Fraley

Now that GIT has made its way into the hands of more than one TechComm department, we thought there was no better person to do a basic session for the T.C. Dojo than Klash. Thank you for joining us today, I'm going to switch the control panel over to you and Klash said he will take questions as we go. So, if you want to ask your question directly to Klash, just let me know and I'll unmute you.

[00:00:51.100] - Liz Fraley

Klash, show your screen. It's all yours.

[00:00:55.950] - Karl Klashinsky

I believe I've shown my screen. Liz, can you just confirm you've got it?

[00:00:59.480] - Liz Fraley

Absolutely.

[00:01:00.710] - Karl Klashinsky

All right.

[00:01:03.180] - Karl Klashinsky

Welcome, everybody, yeah a little bit more about me, I am too old for this stuff. 30 plus years in the industry now, a lot of it around SCM build and release or as the cool kids like to call it these days, the "buzzword du jour" is the devops world of continuous integration, continuous deployment, etc. And GIT, being the source management system, is the underpinning of a lot of that world today, so I'm going to try to give you a little bit of an overview of GIT versus the traditional source code management, and although I'm going to focus mostly today on hands-on and the basics of using GIT as an individual user, I will talk a little bit about the collaboration models.

[00:01:53.310] - Karl Klashinsky

In other words, how GIT is used to share code amongst people. Then I will go into a bit of a hands-on demonstration, it's going to be mostly a command line interface. However, I will speak briefly about GUIs, which I don't use very much in my day-to-day life. I first started on computers when there were no GUIs and they are still the most productive way to get a lot of things done. However, there is a very, very cool way to use GIT, which is through the GitHub web interface.

[00:02:28.440] - Karl Klashinsky

So, I will be showing a little bit of that off as well. I'll finish up with fielding any questions that have not been asked during, and then I've got a bunch of links, and of course, the standard thing is, you don't know it, Google does. So, I'm sure we all know about that guy. So, in a traditional SCM world you would have  multiple computers or user accounts talking to a central version control server, that version control server would have, typically a large database of every revision of every file that you're interested in, and then the users or the computers would essentially check out the system.

[00:03:20.360] - Karl Klashinsky

So, in this picture that you see here, we see only two computers, but in a large enterprise this could be hundreds, if not thousands of users each checked out. Therein lies both the advantage and the disadvantage of a traditional model in that, the advantage is that with central server, you have a strong level of control. You can put firewalls around it, you can do tracking, you can back it up centrally, etc.

[00:03:52.010] - Karl Klashinsky

The downside is, and I deal with this in my day-to-day work, scalability is a major issue when you get to an enterprise with thousands of users, you have a single point of failure. If you have multiple site situations, it's often not practical to access a server from, say, India to Sunnyvale in order to check out a one gigabyte repository. That would not work very well, and even once you do the bulk of the interactions with the server, you find yourself on the client side being dependent on the server for many operations.

[00:04:32.070] - Karl Klashinsky

So, if I'm the user on  computer A and I've made changes to a file and I want to compare it to a version, a prior version, then that's typically going to require a round trip to the VCS server and again, that has scalability issues and performance issues. Moving on to the next slide, the GIT-distributed model is a little bit different. Terminology varies a lot in in the usage of GIT,

[00:05:04.470] - Karl Klashinsky

but when I say the term GIT tree, I am referring to both GIT repository, which is the version database containing all of the versions, and a working tree, that contains a checked-out set of files from that version database. So, in the GIT-distributed model, all SCM data is replicated. So, if I'm on computer A, I have a complete copy of the version database, not just the files that I'm working on, and ditto for computer B. So, this does of course have some overhead with it because you are replicating this database in every GIT tree that is in existence.

[00:05:49.290] - Karl Klashinsky

However, from a practical point of view, a lot of smart compression and other techniques are used within the database to keep the files, sorry, to keep the database size surprisingly manageable. I don't have any concrete numbers, but I can tell you I've done experiments and even with code bases as large as the 20 million line code base that we have at Juniper, the size of the actual repository database, the version database, it's not negligible, but in the modern age, it's not significant enough to be a high cost.

[00:06:30.180] - Karl Klashinsky

The big advantage with this is, that each GIT tree is completely autonomous. You are detached from the server, even if you are working in a cafe that does not have Wi-Fi, you have full access to the version database. So, you can do comparisons, you can do history searches, and because of this, these SCM operations that would typically require a round trip to the server in a traditional model are all local operations. So, they're very fast.

[00:07:01.710] - Karl Klashinsky

And another advantage is, that you unleash the network effect here because with GIT, any GIT tree or any GIT repository, can share with any other GIT repository. So, if I'm on computer A and Liz is on computer B and we want to collaborate but don't want, or are not yet ready to share our code with other people who are using the repository on server computer, we can exchange transactions back and forth between computer A and computer B. It's very, very powerful, but you have to use it with a bit of caution and discipline.

[00:07:43.150] - Karl Klashinsky

And also, having a complete copy of the version database within your GIT tree makes it very easy to switch between snapshots, branches, releases, etc. The net effect of this is that, historically or traditionally, if I was working in a traditional client server SCM model and I was having to work on multiple releases of the code base at the same time, I would typically have multiple working trees, one for each branch, one for each unit of work that I'm working on. With GIT, because you have this ability to switch within one working tree from one snapshot to another,

[00:08:30.530] - Karl Klashinsky

the net result is that you typically have less working trees and you just switch the context within that tree. So, a quick comparison of the work flow that one would typically have when going back and forth with the traditional SCM versus the GIT model; the standard thing that you would do in traditional is, you would check out, edit, compile, debug, test, and update means to essentially merge in code committed by others. And then the loop there is, kind of, self-evident, but it's the old joke, it's, "when is the editing done? It's never really done." so typically, engineers cycle on this edit, compile, debug, test update cycle until they feel they are ready to commit, and then their code is committed up to the central shared repository. In the GIT model there's one significant and important difference, and that is, that you have the ability to commit locally without actually sending your changes up to the shared server, or up to the next level of the repository system.

[00:09:47.620] - Karl Klashinsky

This is really, really a strong feature of GIT, the mantra of GIT users is, to commit often, any time you have your working code or your documents or anything else that you're version controlling, any time that you have a state that you believe is worth saving, you should go ahead and commit it. You should think of this as, how often do you hit the "save" button when you're writing a document? In GIT, you want to commit as often as you would hit the "save" button.

[00:10:22.630] - Karl Klashinsky

It gives you an automatic backup, and it also maintains a history of your changes.

[00:10:29.030] - Karl Klashinsky

So, very, very useful if you decide at the end of the day, that something that you did around 10 o'clock in the morning is something that you wanted to undo, because you have the ability to go back and look at exactly what you did at that point in time. The additional operations that you see here, are the clone and the pull, and those are mostly just terminology nits, which, hopefully will become clear when we move forward. So, I am going to focus mostly on the individual using GIT.

[00:11:04.280] - Karl Klashinsky

I believe the idea here is to get people comfortable and familiar with actually using GIT, and the collaborations are sort of, the next-level subject, and I'm going to provide a couple of examples, but not really going to demonstrate them much today. So here's one model, this is used by open source, a lot of open source projects. The GIT repositories are logically organized as a tree, the internal nodes  or the non-leaf nodes, are considered integration points or where multiple people can share their work. The shared repositories typically have a more controlled access model.

[00:11:50.980] - Karl Klashinsky

You may not be able to push directly to them, you may have to ask somebody to grab your changes and pull them into that repository, you may need to submit them by email. There's multiple models there that are kind of advanced topics, but the point is, that the shared repository becomes something that is a little bit more controlled.  Individual developers tend to work on their leaf nodes, and I should emphasize again, each one of these little bubbles in this diagram is a GIT tree, which has both a repository, so a full snap, a full copy of the version database, but also their individual working tree where they're making their individual changes.

[00:12:34.780] - Karl Klashinsky

And of course, this just pops up a level, if you will, until you have a full tree, and at the root of the tree, that is considered to be the master repository. So, using the lingo of the open source geeks, what you have is, "upstream and downstream." And so, in this model here, the ultimate upstream source is the master repository, downstream from the master repository are our two shared repositories. Downstream from them, each of those have two shared and of course, each of the third level repositories  have three developer repositories downstream.

[00:13:23.100] - Karl Klashinsky

So, the authority for each internal node has control over those immediate, or has some level of access to the nodes above and below. This is typically called the Tree of Trust Model. It's almost borrowed from, you know, spy agencies where they limit the amount of knowledge that any one node has, in the amount of interaction in order to prevent the system from devolving into total chaos. This is the model that Linus Torvalds uses for the Linux Kernel development.

[00:14:00.550] - Karl Klashinsky

He uses the term "trusted lieutenants" for the owners of each of the internal nodes, and he limits exactly which trusted lieutenants he's willing to talk back and forth to. This is actually used by many other open source projects, and Linux Open Source Project is, of course, much larger than this tree, but hopefully it illustrates the model that is at work. Another model, anybody who's heard of GIT, and has probably also heard of GitHub. GitHub is a startup. They're based in San Francisco actually, and they're using the standard, what is known as the Freemium Model of Financing.

[00:14:47.670] - Karl Klashinsky

So, you can create an account on GitHub for free, you can put your code on there for free, you can do much of what you want. If you want some of the more advanced features, or if you need larger levels of functionality, then you pay a subscription fee and work with it. We at Juniper have a corporate account on GitHub, you'll see a little bit of that in a couple of minutes. This allows us to use GitHub, we've effectively outsourced our SCM operation. Whereas in a traditional enterprise company, you would typically have an internal group and you would buy your own servers and support your own SCM infrastructure.

[00:15:33.390] - Karl Klashinsky

With GitHub, you get to outsource that. With the GitHub model, it will support multiple models, but the most common one is kind of, like the traditional SCM where you have a hub and spoke, which essentially, is just a client server model.

[00:15:50.480] - Karl Klashinsky

An individual developer can fork a repo and and then work on it,  and then once they're done, they submit a pull request off to the owner of the original repository. The key to know here, again is, the developer cannot push directly to the original repository, they have to submit a request. The owner of the original repository can essentially create a review process during processing of that pull request, and I'm actually going to demonstrate that. So, hopefully I know that's probably a bit confusing, but hopefully the web interface will make it a lot more user-friendly.

[00:16:39.470] - Karl Klashinsky

I spent a few minutes this morning Googling around, found some pictures, here's some other models of collaboration and repository structure for network of GIT trees and repositories that, you know, people are using in various projects. This is just a handful,  there are, of course, plenty out there. So, if there are no questions on the presentation point, and I see that the questions is currently showing empty, I'll go ahead and go into the hands-on mode.

[00:17:17.550] - Liz Fraley

Did you want me to ask your poll questions, just in case?

[00:17:22.010] - Karl Klashinsky

Oh, absolutely, yes, please.

[00:17:24.860] - Liz Fraley

All right.

[00:17:25.260] - Liz Fraley

So, the first question, folks, if you pay attention to the thing, it should switch, there we go. Really quick, are you familiar with the Unix-ish CLI? Yes or no? So far,  most people are saying, yes, there are a couple of no's, maybe 30%. Ah, it's changing. All right, pretty good, pretty close. All right, folks, one more question,  are you familiar with the older SCM's like Subversion, CVS, Perforce, Clearcase, have you played with any of them, or had to use them at work in any respect?

[00:18:08.070] - Liz Fraley

Oh, everybody's seen at least one of these pretty much. All right, all right, and the last question, are you more interested in using GIT for collaboration, or for saving private work?

[00:18:21.700] - Liz Fraley

We're expecting collaboration, so, yes for collaboration, no for private work. Wow, everybody's saying collaboration, that's so exciting.

[00:18:31.950] - Karl Klashinsky

Ok. 

[00:18:34.070] - Liz Fraley

All right, and I'm going to switch presentation back to you, you'll have  to share your screen again.

[00:18:40.810] - Karl Klashinsky

There should be a button around here somewhere, right?

[00:18:42.760] - Liz Fraley

Here we go.

[00:18:43.470] - Karl Klashinsky

There it is. Ok, well, thank you, I'm not going to be able to demonstrate a lot with respect to collaboration, that would've required a little bit of pre-setup work. We could always arrange a follow-up presentation if that made sense.

[00:18:59.800] - Karl Klashinsky

But you will see a little bit of that here, in what I'm going to do. So, before I do that, there's one small area here that I needed to clarify, which is kind of a very low level hands-on thing. I alluded to this earlier, didn't go into a lot of detail, in my mind or in my terminology, I use the term "GIT tree" to define both a working tree, and the GIT repository, i.e. the version database that comes along with it.

[00:19:37.440] - Karl Klashinsky

And most of what you do with GIT is commands that change your working tree or your GIT, or your repository. In various ways, saving code, checking out code, etc. There is an interim area that GIT uses, called the staging area. It's also known as, the index. It is a little bit hard to explain, but effectively, you don't make changes directly in the GIT repository, you stage things into the into the index or the staging area using certain commands, most notably GIT "add." GIT "add" is the magic flag that says, "I intend to commit this file."

[00:20:23.740] - Karl Klashinsky

And this is the important point, I intend to commit this file in its current state, because if you then make further changes to it, your working directory will be different from your index, which means that if you commit what you get, what you commit will be different than what's in your working directory. And I'll try to take a moment to demonstrate that, but again, it is a little bit of a head scratcher for people when they first use GIT, to understand that there is this interim hidden staging area and you need to interact with it in order to make sure that what you commit is what you think you committed.

[00:21:02.380] - Karl Klashinsky

So, I'm going to switch over to my command line windows and I think I will bump up my font sizes. Liz, can you confirm that these are relatively legible?

[00:21:17.200] - Liz Fraley

I see two, I can read them, but I am on a big screen. Anybody else? Pop something into the chat window, a question, if you can't see it.

[00:21:26.290] - Liz Fraley

Also, remember we're going to publish this on YouTube and you should be able to watch it full monitor screen there, so, but I'm recording on a big screen, so hopefully it's getting good visibility for that, too. Looks good to me, klash.

[00:21:42.880] - Karl Klashinsky

Ok, ok, very good.

[00:21:46.800] - Karl Klashinsky

So, in the directory or in the window on the right, pardon me, I'm actually looking at a repository I set up to track and develop some work that I was doing last year, and so, this is a GIT working tree. So, what I have here, that I'll emphasize is, there is this magic .GIT directory. This is effectively the version database, the repository part of the GIT tree, so, please resist the urge to do anything to this directory, especially remove it.

[00:22:28.820] - Karl Klashinsky

If I remove this directory right now,  I wouldn't lose my working tree, I'd still have the snapshot that you see in front of you, but I would lose all of the history and stuff that went along with it. So, for those that are really curious, you can peek underneath the hood of this .GIT directory, it's just a bunch of files. You can see things like an object directory and branches, and there's pretty good clues as to what those things would be. Once you understand GIT a little bit better it's kind of fun to poke around in here and sort of, see how GIT stores things and how efficiently it does it. But again, kind of an advanced topic so I will not do that here.

[00:23:14.370] - Karl Klashinsky

There are a few commands in GIT and git-help is one of the ones you should get familiar with very quickly. As you can see here, git help will give you a bit of an overview, and as it says at the bottom there, you can get a list of all of the commands and you can see that there are a lot of commands and you can, of course, do "help" on any specific command.

[00:23:42.780] - Karl Klashinsky

So, if I say git help diff  I get the full man page for the command which has, as you can see, lots of detail. Another useful one is just to enter the command with an H and that will give you a shorter version of the usage, typically just the command line synopsis. But of the commands that you're going to want to use the most, and this is typical for a lot of environments, the most common commands that you're going to use are, checkout, log, diff, add, commit, push, pull, show. 

[00:24:29.160] - Karl Klashinsky

I probably should have listed those in the slide and perhaps I will do that and make those slides available, but let's take a quick look at some of them.

[00:24:37.590] - Karl Klashinsky

So, git log  very, very quickly just shows you the log history. This one's relatively boring because it shows only mine, and that's because I created this repository to be able to track my own work, pure and simple. So as you can see, it's not a long history here, but I was using this again at my own work back in, I said last year, but I meant 2014, obviously. Let's take a look at any one of these,

[00:25:08.730] - Karl Klashinsky

you see that each commit is identified by this long, unique identifier. You can typically just take the first six or eight characters and that will actually be enough to be unique for any individual command, so, for instance, if I wanted to see just that commit, I say git show, it gives me again the commit information I had at the beginning and then the actual diff of the code that  I made on that particular commit.

[00:25:40.370] - Karl Klashinsky

And if I wanted to see what the diff between that and the most recent commit in my tree is, this shows me basically everything that changed since that commit. So, this is all relatively routine stuff hopefully, but I think a more interesting exercise for you folks would be to see, I already have some files, how do I go about putting them under GIT control? In the window in the left I have this one directory, WIP, that is not yet....

[00:26:17.090] - Karl Klashinsky

Here it is, just a bunch of, I'll be blunt, these are some hacks that I had to do for some sysadmin stuff, but I decided that I want to keep track of them. So, turning this into a GIT repository is as easy as doing this, I'm going to say, git init my current working directory and that's going to create that .GIT directory again, but it's going to be relatively sparse. Now, what I'll do is, at this point, if I ask what the git status is, which is another important command, see that I'm on my master branch?

[00:26:56.440] - Karl Klashinsky

And I have untracked files and nothing else going on. So, there is nothing to commit and I'm going to go ahead and add all of those files by just saying, git add star and now, when I say git status, notice the difference. Now, here are the changes to be committed, because I have added these to the index or to the staging area that I mentioned earlier. So, these are all now ready to commit, and I'm going to say, git commit bulk add of initial snap shot.

[00:27:40.450] - Karl Klashinsky

And now all of these files were added. Now, if I do a git log to look at the result, as you can see, I had the one and only commit I made just a few seconds ago. And if I do git status, well, there's nothing to commit, everything in my working directory is completely clean. So now, here's the same directory in my...  I'm sorry folks, this is my editor, I'm just going to quickly go ahead and go in here,

[00:28:17.460] - Karl Klashinsky

show you how you would go about doing this. Now when I say git status, you'll notice that it shows "modified one file" and if I show git diff, and by the way, if you are a command line user, one of the things I do appreciate about GIT is the fact that it uses coloring on standard terminal output, which is really useful for things like this.

[00:28:41.640] - Karl Klashinsky

So I can edit it in green,  remove a line, it's shown in red, this is all very useful stuff, in my opinion. So now again, this shows it as "modified" but this change has not been staged for commit, at this point now, if I say git add on that file, and then do git status, now this change is ready to be committed,  it has been staged and I can go ahead.

[00:29:24.550] - Karl Klashinsky

And make a new change. And now, if i use git log to look at my output, I can see dummy stuff, right? Now, to show you again, you can do things like, I can say, git diff, what changed from this commit to, like this, and again, it shows me. Now this is a relatively boring example, because I'm only showing you from one commit to the other, but when you have a longer log history, you can show the differences between the string of commits,

[00:30:00.950] - Karl Klashinsky

you can show differences between branches, all kinds of fun stuff. And I can demonstrate that. So, where did I leave that repository? Pardon me. Actually, let's switch over now, because I see we're already past 9:30 and I don't want to keep you too long, what I've shown you is a command line. There are plenty of gooey options available that you can look into, this is just one that I bought myself a few years ago because I wanted the occasional ability to take a look at browsing things graphically.

[00:30:45.540] - Karl Klashinsky

This application is called GitBox, I think it was 1999 somewhere on the net, and I can add a repository that already exists just by navigating to it in the standard fashion. So, there it is, the repository that I created, and I add that,

[00:31:06.270] - Karl Klashinsky

and now you can see that I have a little bit of a browser here that I can take a look at those two commits. A  little more interesting to look at something like this one over here, this is actually one of the repositories that I work with at Juniper, and you can see that it has a far longer and richer history and I can go through and I can browse these almost anywhere and look at these commits. There are other operations I can do as well,

[00:31:38.710] - Karl Klashinsky

I can switch branches, I can do various things.  And so, that's an example of a GUI browser. Now let's talk a little bit about GitHub, and again, I'm moving along fairly quickly here because I feel the need to wrap this up, because of the time, this is one of our groups,

[00:32:05.080] - Liz Fraley

Klash?

[00:32:06.490] - Karl Klashinsky

This is one of our repositories, yes?

[00:32:08.710] - Liz Fraley

We have a question, "will diff work on binary word processor files?"

[00:32:15.520] - Karl Klashinsky

The diff will not. Overall GIT will work well with binaries, but it cannot really show you the differences between binaries. Now, that's the short answer, and then the long answer is, that like a lot of SCM's GIT can actually, you can extend GIT by adding handlers for specific source types. So, if you have some kind of a tool that is capable of generating a diff between these binary files, a human readable diff, then yes, you can use git diff. Even if you don't, with regular binaries, you can run a diff on them

[00:33:02.530] - Karl Klashinsky

but of course, if you diff binary files, they tend to be, the diff tends to be very large and mostly meaningless. But there are ways to do that, yes.

[00:33:15.890] - Liz Fraley

All right.

[00:33:18.440] - Karl Klashinsky

Ok. So, this, what I'm looking at here, this is a GitHub posted repository, so the name of the repository is listed up here and you see that the keyword "Juniper" as this would indicate, and the lock beside it, this is one of our private proprietary repositories.

[00:33:48.260] - Karl Klashinsky

So, you know, please don't screenshot this, haha just kidding. And then, this is the name of the individual repository and I'm on the code tab right now. So, here within this, I can actually browse. So, I can go and take a look at, for instance, this to-do file. There we go, and so, I can look at the file directly in here, and the nice thing about GitHub is, it actually will allow me to edit these files and save them directly.

[00:34:23.480] - Karl Klashinsky

But in this case, I can see who edited this file last, what the history of this individual file was, if  I wanted to look at that level, and it shows you the commits that actually worked on this file. Blame is a wonderful tool, I dislike the name, I prefer the term "annotate" but this gives you, go through the file line by line and it shows you the individual commit, and which commit, pardon me, added or created those lines of code.

[00:35:03.790] - Karl Klashinsky

This is very, very useful when you're trying to track down a bug, I'll show you how that works in the command line. The jpipe.c file that you see in front of you is the thing I was working on a while back. If I say git blame on that,

[00:35:25.860] - Karl Klashinsky

see, I get the same type of output. This is on the right hand side, the actual C file, and on the left hand side, you see that there is a commit identifier, my name, the date, and where these lines came from. Now, the first batch is mostly going to be, it looks like I didn't make any changes from this file after the initial add. I'd have to look for a better example to give you, something more useful, but that would be time wasting.

[00:35:57.830] - Karl Klashinsky

So, going back here,

[00:36:01.690] - Karl Klashinsky

we can look at other aspects, I can look at other branches, so, you see that there are multiple branches of this repository. Here's one that I had a while back when I was doing some testing. And I can look at all of the commit history. Again, this is showing you the same sort of things that I was doing with the command line, only through a web interface, which is kind of handy for those that are not familiar with the command line, but it's also just generally useful.

[00:36:45.240] - Karl Klashinsky

Now, I described a little bit, the collaboration model in GitHub, and you'll see here that there are three pull requests pending. And here they are. So, I can go and take a look at this pull request. So, this is one of my co-workers, Kamlesh, and he has submitted a pull request, and if I look, there is only one commit actually in the fork that he had and I can look at his diff. If I see something that I have a concern with, I just get the plus...

[00:37:23.630] - Karl Klashinsky

"I think this needs work." If I say "comment" he's going to get an email immediately, which effectively is a request for him to make a change here. So, this is a code review built right into GitHub. It's not fancy and it's not nearly sophisticated enough, but for minor collaboration, it's more than adequate. Other neat things about GitHub, it also has some issues tracking, i.e. problem reporting built in, we don't use it, but it is there. Again, it's not suitable for a lot of very sophisticated enterprise-level problem reporting requirements, but for rudimentary collaboration, GitHub is more than adequate.

[00:38:14.050] - Karl Klashinsky

Taking a quick look here. If I wanted to download, all right. And I think I'm going to have to wrap up here because I'm looking at the time. The only other one that I wanted to point out, I hear you chuckling, Liz, is, that the other nice feature built into GitHub is, that you can have wiki pages attached to each individual repository. So, we have various wiki pages attached directly to this repository, which are, as you can see, very easy to maintain online documentation for a repository, and again, it's attached and versioned directly with the repository.

[00:38:56.640] - Karl Klashinsky

It's not in a separate system, it's not in a separate location, it's all in one piece. And if I ever wanted to clone this repository, see this item down here where it says "clone" if I wanted to have a working copy of that anywhere I wanted, I could just do this. It's not going to let me do that, I'm sorry. (I need to switch to...) Ok, at this point, I'd have to do some authorization set up, and again, I think that's a bit of a diversion.

[00:39:38.270] - Karl Klashinsky

So, forgive me for the rather whirlwind view through this, but if I had to guide you all, I would say, get yourself a GitHub account. That gives you a place to upload your GIT repositories for free. This is essentially free backup. Learn the rudiments of using GIT with those basic commands I mentioned earlier, and the biggest value that you can get from GIT is, the same value you get from using your save key, but with a revision history.

[00:40:09.920] - Karl Klashinsky

And once you start developing a working familiarity with GIT, it starts to become very, very natural, and then collaboration is a very easy add on after that.

[00:40:24.190] - Karl Klashinsky

And wrapping up, I will make this available, but as I mentioned before, there's lots of this stuff on Google. These links were a few that I found from just doing some Google stuff. This nifty direct hands on is very, very cool.

[00:40:43.660] - Karl Klashinsky

I was looking at it earlier, if you hop over to that. Even if you don't have a machine with access to GIT, and I should point out that even Mac, well, not even Mac, but Macintoshes have GIT preinstalled, so do most Linux machines. But if you've got this working tutorial,  it could be a very, very cool way to get yourself started. So it's in thisset  of links here and unless there's anything further, I'll hand it back to Liz.

[00:41:19.490] - Liz Fraley

All right.

[00:41:21.370] - Karl Klashinsky

I'm going to switch back briefly, tell you guys what's coming up. This is the time for you to type in your questions if you haven't already. All right,

[00:41:30.790] - Liz Fraley

Coming up in January, this is less than two weeks away,

[00:41:34.210] - Liz Fraley

We've got T.C. Camp coming up, and as a coincidence, two people from GitHub, two of the actual trainers are coming out to do a two hour workshop. So, if you're in the Bay area or in a close drop distance to do it, we do it on a Saturday, you fly out Friday evening, you don't even have to miss work. You can do that, or there's content strategy for TechComm, UI/UX, design for technical communicators, keeping yourself marketable, and Adobe is trying to come in at the last minute with a really cool session on migrating from word to XML DITA.

[00:42:06.310] - Liz Fraley

If you have never been to an unconference, it's amazing, go to tccamp dot org [CLOSED], you can see from other people what they did. I think Tom Johnson from  "I'd Rather Be Writing" just did a really great article on it too.  Our next TPC Affinity Group meeting, if you haven't ever been to one of these, too, this is member driven discussion groups online in a supportive, confidential environment, it's the same people every time. We do have some openings in the techcomm one.

[00:42:33.490] - Liz Fraley

Our next session is, "Stories of Experience and Experimentation" with conref, keyref, conref, and profiling, conkeyreth and profiling, it's guaranteed to be a really great discussion. Our next T.C. Dojo is "Authoring for Reuse" Keith Schengili-Roberts from IXIASOFT will be here in February.

[00:42:52.810] - Liz Fraley

He hasn't got his description to us yet, but if you sign up today, you can get the updated description automatically, and where do you do that? tcdojo dot org. The sessions coming up are listed at the bottom, we've got Kit Brown-Hoekstra also coming up, and some really good other topics, it's amazing. You need to vote on the sessions because these are all about you. Tell us what you want to learn and we go find experts like Klash, here, to teach it to you.

[00:43:20.530] - Liz Fraley

All right, thank you, Klash. Let's see if we've got some questions yet. Oh, I think you've blown everybody's mind.

[00:43:27.550] - Liz Fraley

I had one, of the things I really like is the notion of continuous commits, right?

[00:43:34.150] - Liz Fraley

For techcomm this is traditionally difficult, right? Because writers tend to wait until it's done, or some definition of done, before sharing their content with other people. But like with your hacks, you can have more repositories for extra things you do and manage to make your life easier.

[00:43:49.810] - Liz Fraley

Any words of advice for getting over that? If you're looking forward to peer review, making your life easier, any words of advice for our techcomm folks?

[00:44:01.600] - Karl Klashinsky

Yeah, it's mostly just a mindshift. And so I would just encourage people, you know, to think of the commit not as this sort of, carved in stone, can never be changed again. To think of it like your save button. But with the thought that, if you wanted to undo that thing you did yesterday, because now you've realized you wanted to undo it, it's a lot easier to do. GIT has a couple of ways to be able to reverse an individual commit from a chain.

[00:44:39.670] - Karl Klashinsky

Sorry, a little off topic. Bottom line is, just think of commit like your save button, and commit as often as you would save, because having that snapshotting is really good and it's a bit of an advanced topic but you can Google it. Once you've set up your working repository, you can set up another one, say, in a Dropbox, and you can automatically back up your work to something other than your machine, which is another encouragement for saving or committing.

[00:45:12.850] - Karl Klashinsky

It's just a different mindset and it is one that you have to get used to, if you'll pardon the pun.

[00:45:22.810] - Liz Fraley

That's actually a good way to think about it, I like that.

[00:45:26.760] - Liz Fraley

Think of it as your save plan, i love that.

[00:45:30.530] - Karl Klashinsky

There's a lot of puns and usages of the, "you git" g-i-t in place of the word "get."

[00:45:39.110] - Liz Fraley

Indeed, all right.

[00:45:42.380] - Liz Fraley

We've got a little difficult question, I think it's in three parts, but let me get through it. "I think this is a hard question, but where's a good place to start understanding different branches and folders? A lot of the writers I know are very familiar with folder structure and maybe check-in and check-out. But multiple snapshots and knowing what version is going where, is brain hurty."

[00:46:06.980] - Liz Fraley

Any suggestions on where to start?

[00:46:10.850] - Karl Klashinsky

Yes, it is a tough question. Again, Google would be your ultimate source. There are lots of tutorials out there, but the one that was in my list of other resources and maybe Liz, I can send it,

[00:46:26.120] - Liz Fraley

I can send it back to you, yeah.

[00:46:29.490] - Karl Klashinsky

Yeah. It's the git-scm.com/book, and now, that is one of the better books on GIT that's out there, and the entire book is online for free. And it has some good, it has a very, very good getting started tutorial, and dealing with branches with GIT is a little bit tricky because there's the concept of upstream branches versus local branches and I would just Google the term "remote branch versus local branch in git" and start looking at some tutorials there.

[00:47:12.640] - Liz Fraley

You said, git.scm.com/book?

[00:47:19.180] - Karl Klashinsky

git-scm.com/book.

[00:47:19.330] - Liz Fraley

Dash, there we go. All right, because I want to put this in the chat window and then you guys can get at it really easy. All right, that should work because my other one was not working.

[00:47:30.220] - Liz Fraley

Looks great, excellent. All right, so, yeah, if you can provide your slides to us, that would be great, because then that resource is there for everybody to do, or if you want to put it on SlideShare and point me to where you have it, even better. And then I'll put that on the recording page at YouTube also. So, if you haven't signed up or subscribed to the YouTube channel, that's how you do it. It's right there on the screen.

[00:47:54.880] - Liz Fraley

Sign up and when the video is posted, hopefully later today, you'll get a copy and be able to watch it then. All right. Thank you, Klash, I appreciate it. And I appreciate everybody for hanging out this long. This is a complex topic and I guess maybe, just the first of many we should do. All right, thank you, Klash, that was great.

[00:48:14.180] - Karl Klashinsky

Thank you.

[00:48:16.850] - Liz Fraley

Bye everyone.