 In this video, I'll demonstrate how to use Git as a version control system for collaborative writing with LaTeX. This is particularly useful for mathematicians who want to collaborate on writing documents together. So I'm not going to focus on using Git for things like supporting compiling and testing and so on in all the various programming frameworks. Instead, I'm going to focus primarily on how you can write tech in a coherent way with collaborators, keeping track of changes as you go. I'm doing this on a Mac. The procedure is essentially identical on any Linux computer. Say if you're running Ubuntu or Debian or Mint or some other variant of Linux. So I'm going to need two things open. First of all, I'm going to need a terminal and a web browser. Now there are three main services that people often use. You actually don't need to use any of these services for Git to be effective, but it does make everyone's life a lot easier. The three services that you may have heard of are GitHub, Bitbucket, and GitLab. Functionally, they're all essentially identical. The differences are in their commercial business model and details of the user interface, but they all have the same essential features of collaborative repositories, issue tracking, comments, and so on. In this demonstration, I'm going to use GitLab. With GitLab, you can either make an account or if you have one of the existing accounts for Google, Twitter, GitHub, or Bitbucket, in fact, you can use any of those as a single sign-on system. So I'll use my Gmail account here. Okay, so when you log in, you'll see a list of projects which you participate in or which you've starred. In this case, I'll use example for video. So this is the front end for a repository online. There's a lot of detail here, most of which you don't have to pay attention to right now. The key thing to recognize is that this repository is accessible from your computer to be cloned using one of two protocols, either SSH or HTTP. Of course, SSH is the standard secure shell system ubiquitous on Linux, BSD, and Mac computers. It's also possible to use on Windows using Putty, but that's a subject for a different video. So in order to access a repository through SSH, I need an SSH key. This is an encryption key that both identifies me and ensures the data is valid and secure. So in a terminal, if you don't already have an SSH key, you can generate one with the command SSH add. Sorry, SSH key gen. You should save it in the default file. So when it says enter a file where you want to save the key, just simply hit enter. Now your key should probably have a passphrase, so that if someone steals your computer and they get access to the key, they can't access all of your personal information. So come up with some passphrase, type it twice as always for verification, and you get to serve mysterious output. But the key point here is that in the directory called .ssh inside of your user account, there are now two files. Let me go there. The two I'm looking at are idrsa and idrsa.pub. This is a key pair. Idrsa should be kept secret and private, whereas idrsa.pub is what you send to other computers, other servers, and other services to make sure they can identify you. So if I look at this file using, say, cat as a standard print some output command, the pub file looks like this. It says it's an ssh key of type RSA. It has this, which is some encoded, you know, large number for the purpose of doing RSA encryption. And then it has a comment, which is usually just your username and the computer name. Okay, so to make GitLab really work, in your account, under settings, you have to add this key, ssh keys. And so, again, I want to account settings, and then under all these various things I have ssh keys. And I'm going to paste in this key. And this is, I'll just call this sample for video key. So now if I look at that same list of keys, that key is now listed. So as long as I'm on a computer with that key, namely this computer, I can ssh into GitLab. And access this repository. So, back on the command line, what I will do is I will run ssh add. And then ask me for the past phrase that unlocks my key. So now this is identity added. So if I try to ssh somewhere, it's going to try to use this key to both authenticate me and keep the connection secure. Okay, so that's how we set up our account to access information. You only have to do that once, generate a key and upload it. Henceforth, that identifies you. Let me go back to my projects. So this is a repository I want to clone. Here's the link to clone it. So let me do control C. And I will do ssh, sorry, I will do git clone. And just paste in that address. GitLab.com, then my username slash example for video.git in this case. So it'll look something like this. This git command is calling ssh. This is sshing to git lab using my private key that we just generated. And then it's making a local directory. So if I list my local directories here, the most recent one is example for video. And it made that directory which is now a clone of this. Okay, so this is currently empty. Let me add some important things here. So let's suppose I add a readme file, my awesome project. I can add a quick readme file. It's useful to have it say actually something useful, of course, maybe a quick description of your project, but then some other instructions for someone who might want to know how to use it if you're doing collaboration. So for example, I could say the following. Please do not commit PDFs, aux files, or other short-lived results of compiling Leitech. This makes the repository messy. Please only commit tech, Bibtech, PNG, JPEG, et cetera, as necessary to compile. The thing about a source code repository like GitLab or GitHub is that you really want to keep track of the things you are physically inputting so that you can run differences on them historically and see what you've changed. The actual PDF that's being output, everyone who has access to a repository can generate that themselves using PDF, LaTeX, or whatever their favorite LaTeX compiler is. So really the things that you generate, your tech file, your .bib file, any images that you're going to include with slash include graphics, that's what you want to include, much like you would say when you're uploading to the archive. All the aux files and BBLs and log files and even the PDF or DVI itself, you don't really want to commit those. This will be automatically generated. Okay, so now this is a file I want to add to the repository. So I say git add, readme.nbmd and I can say git status. So git status says, first of all, branch master. So git keeps track of history in a sense of branches and commits. And it says I've added a new file and I'm going to commit it. So I say git commit and you can give it a message like if you say dash em you can say I added a new file or the readme. So this is now committed. However, it does not yet appear on the online repository. What I have to do next is push it. So if I say git push, git remembers where this repository lived on GitLab and it pushes it there. So now if I reload this web page, notice this has my readme file as the front page. There's a set of instructions for people to use. That's the usefulness of a readme file. Moreover, if I look at the files, it lists the readme file, which I can view. If I look at commits, it shows that I added this commit with my message. I can examine this and I can look at the files that were added and what was changed in them and so on. If there are multiple branches, you can examine the branches. Currently there's only master. And you can look at a historical tree of all the changes and what's changed from change to change. So one thing that might happen is you want to have a tech file. So here's a new file you added. What I'm going to do is git add and push. Ah, I did not commit. This is one of the key ideas is that you always have commits. So the commit is happening locally on your computer and you sort of, whenever you push, you look at all the most recent commits since your last push and you push them up to the server. So git commit, let's say, added a simple tech template. Git push. So now you can see under files, I have both files. If I look at commits, if I look at the commit itself, I've added a new file. You can look at this in various ways, inline, white space, etc. Okay, so now consider the following situation. Perhaps some other user has made some changes and you want to incorporate them. You would do that with git pull. So usually what happens is you say git pull and that pulls in changes from the remote repository. You edit, edit, edit using your favorite editor and then you git commit to commit those changes and then you do git push to send them back. So it's pull, edit, commit, push. Pull, edit, commit, push. Over and over and over again. The key advantage of this is you can really keep track of history. So for example, let's suppose I make some changes to the readme file. Like I want to do that. I want to put a paragraph break here and maybe I want to change some grammar and maybe I want to edit my tech file a little bit too. Clearly I had a typo in here. Of course I'm adding this in vim for the sake of being quick for this video, but you could use tech shop or anything else. As long as it's something that reads and writes the file, you can use it. So if I look at this directory, of course, I've got my readme, I've got my example.tech, but I also have this other garbage, oxloginpdf. I'm going to add those to a file called .gitignore and the reason is that if I do git status to see what it's changed, I don't want to see all those files. So for example, let me go back and change this. Git status always tells you sort of what's changed since your last pull and it says I've got all these untracked files, example, oxloginpdf. You're going to have those every single time, so you might as well ignore them. I'm going to add the .gitignore file so it stays with the repository status and so now if I commit, I'm going to commit this file in those two changes. So I'm going to give it a message say updated tech, added, oops, let's type correctly, updated tech, added ignore file. Now I'm also going to use the command dash a to say commit everything. Now I'm going to push and it's online. So now if someone looks at the repository, they see the current files, but I can look at the commits and see what's changed. So for example, the most recent commit, you can see line by line what changed. I changed this typo and .coment document. I added this line, I added that notice, right? So you can go through and really see exactly what changed, even character by character. This is extremely useful for collaborative help because you can see, oh, that person only worked on section one. Or the changes to section two and three because there weren't any. Okay, so the only other subtlety that there is in using Git is that sometimes two people have worked on the same file at the same time and they've both committed. In that case, you have to do what's called a merge. In almost all cases, merges are automatic. You'll pull, Git will warn you that there's a merge. You'll say git merge, and you'll commit and push back. The only situation that won't work on is if two people added exactly the same sentence or exactly the same line in a way that cannot be automatically disambiguated. So if I rephrase a single sentence one way and you rephrase the same sentence a different way, it's very difficult, of course, for a computer to figure out what to do. In that situation, what you do is you look at both, it gives you both versions of the file and you simply manually decide which one you want to go with. Obviously, that's always the issue with collaborations is at some point you have to decide exactly who's going to take precedence when writing a certain sentence. However, for most projects, different people are working on either different paragraphs or different sections of the same file or maybe even on different tech files. Maybe one person is generating images while the other person is writing some sort of method section. In which case, Git just keeps track of all the changes. It knows who did what. You can dial through it historically and keep track. If you ever want to know what's new in the repository, you can get the poll and it'll bring you up to date. Okay, that's all for now.