 Hello, this is Brian Rowe with LS NTAP, and we've got a special webinar today with Gwen Daniels of Illinois Legal Aid Online, going over GitHub, BitBucket, some of the Drupal customization. So I am Gwen Daniels, I'm the technical director at Illinois Legal Aid Online, which is a fancy way of saying that I am the lead developer on our statewide website. I write most of the code that is on our website, including the code that is on our soon to be launched Drupal site coming in July. I'm also the maintainer of the Drupal contributed module for Google Groups, and I'm going to talk today about using GitHub and BitBucket for Drupal projects, although a lot of the GitHub stuff is also applicable outside of the Drupal community. So what we're going to talk about today is what is Git and why you should be using it, how to set it up, and what are your options for using Git. I'm going to go through and do a couple of demos of how to actually interact with Git, and then I'm going to talk a bit about GitHub and BitBucket, which are cloud-based hosting platforms for Git projects, and where to go next to learn more. So what is Git? Git is a code management tool, version control system, think document management for software. If developer A goes out and makes a change to a file and developer B is working on the same file, you don't want them overwriting each other's work. And so what Git does is it allows each individual person who's working on the code base to have a complete copy of the entire website locally and make their changes and then commit those changes up to a remote version, which is then deployed on an actual website. Why you should use Git? For our own projects, it acts as a backup. If I deploy something on our production website that is so incredibly wrong, I can also undo that. If for some reason the website blows up and I don't have a good backup of all of my code, Git has a copy of it, and every person who has made a copy of our Git repository has a copy of it. It makes it much easier to collaborate and it organizes your data. The screenshot here is actually a tree from our prototype folder and every single copy is named after the person who created it in the date because we had no way to do version control on this, which meant if somebody worked on the wrong file, it wasn't in sync with the other changes. We don't have that problem when we're using Git. But if you're not a developer, why do you care about this? Drupal sites all probably have at least two of the following. They either have, well, everybody who uses Drupal uses, has core modules. That's what you get when you install Drupal. I would find it very, it would be very hard to find a Drupal 7 website that does not have at least one contributed module. Most all of us probably use views. That's a contributed module. Those are modules that somebody else, that somebody created and we downloaded from the Drupal website and installed on our server. And then some of us have custom modules that we either wrote ourselves or hired developers to write. For project managers, you should absolutely be asking your developers if they use Git or another version control system like Subversion. Because they absolutely should, it benefits you in the long run as well as the developer. Another reason why it should matter is that starting with Drupal 8, which all of us will eventually have to upgrade to, all of your configuration lives in code and not in the database. That means that if you go into your Drupal site right now and create a content type, or add a field to a content type, or create a new user role, or add a new permission to a user role, all of that information, starting with Drupal 8, lives in code and not in the database. That means that you can undo anything that you do and through the website user interface if something goes wrong. In Drupal 7, it still lives in the database, but you can't export all of your configuration to live in code via the futures module or the futures builder module. There are basically three ways in which you can work with Git. You can do it in the command line. It's not scary at all. I use the command line 99% of the time. You can use a GUI client like GitHub Client or Source Tree, which is Atlassian's Git Client, and the GitHub Client integrates fantastically with GitHub. Source Tree integrates very well with Bitbucket, instead of created by the same company. If you are doing development work and you use an IDE, such as PHPStorm NetBeans, which is free, and Eclipse, which is also free, then you also have Git tools that are integrated into that platform. I use PHPStorm. I almost never use the Git tools that are in there, unless I need to undo something that I've done. Or review merge conflicts. To Git, it's pretty easy. Windows is actually the most complicated platform to do it on. But all you have to do is download Git from the Git website or install a client like GitHub or Source Tree. For Mac users, all you have to do is open terminal and type Git. It'll prompt you to download the appropriate tools, or you can, again, install a GUI. For Linux, it's even easier. You just type in sudo yam install git or sudo apgit install depending on whether you are using a Red Hat flavor of Linux or a Debian flavor of Linux. So how does Git work? Basically, when you install Git on your computer, it creates a working directory for your project. And that is where you do everything. When you're ready to say you're done with something, you add it to the staging area. And it sits there committed. And eventually, you will commit it to your local repository when you're really done. And then from there, you can push it up to a cloud repository. Until you've actually added, committed, and pushed, it's only going to live on your local machine. You can also use Git pull to pull down changes that somebody else may have done on their copy of the repository. So I'm going to walk through a couple of examples. Really, there's four initial commands that you need to know when working with Git. And they are Git init, Git clone, Git add, and Git commit. And I'm going to start with Git hub to do this because it's easiest. And it's probably what folks who aren't doing development work all the time will probably start with. With GitHub, with GitHub desktop, all you have to do to create a repository is do new repository. Give it a name. And what it did was I created a folder on my computer, initialize Git. And now if I start dragging full files in here, you will now see that it's added a file into this directory. So at this point, it has added the file. And if I say I did something and committed, I have now committed the file locally, but I have not published it to a GitHub repository. Now if what I wanted to do is actually interact with something that is already in GitHub, and I created a little demo project just for that purpose. So I'll do file, new repository. I'm going to clone it. I'm trying to clone it. It will pull down an existing repository on GitHub. And now I can do whatever I want to with this code locally. And then I can push my changes back up to GitHub. That is useful if you are pulling somebody else's project so that you can use it on your website. And you find something that doesn't work and you want to share back your changes. You can also pull stuff down, make changes, and then publish it to your own website instead of back to the repository. All you're going to do is make a live on your site. But clients like the GitHub client and the Source Tree client make it really easy to not have to know any of these commands. Because if I make a change, so I've got this readme text file that is in this repository. And I'm just going to, there's my change. You'll see that it now will show the uncommitted changes that I've added this line. It makes it really easy to see what has been changed in a file. But at this point I haven't done anything. All I've done is made the text change that's sitting on my local machine. It's not even added to Git. But now I'm going to go ahead and add and commit it. I'm going to tell it what I did. I added hello. And now I'm going to commit the file. And as soon as I hit sync, the GitHub client will actually send it up to GitHub. And you'll see that the last commit was 27 seconds ago. And you can see exactly what I did. And now anybody else can go and pull all of my changes off of GitHub into their own copy of the repository. If what you want to do is do this on the command line. And this is what I'm doing right now is just creating a directory on my Mac. I could do git event, which will create a new git repository. I can do git clone. And then GitHub will tell you, there's a little clone link, what the URL to clone that repository is. And now it will actually download whatever's in GitHub to my local machine. I'm going to go back and edit this read me one more time. I just did git add a, and it will add anything that I've created new. This is not behaving like it. Git status is useful to see what's going on with your Git repository. And as you can see, it didn't do what it was supposed to have done. I put the file on the right folder on my computer. And now you'll actually see that it tells me that I've modified the read me dot text file. If I do git add a, that's going to add everything that's changed, which in this case is just one file. I could do git add, and then just the name of the file. And that would just add that one file if I had made changes to 20 files, and I only wanted to commit one of them. I can then just do git commit. I'm going to always want to add a message so that it knows what I've done. I added high two sec, high two sec. And now if I do git push origin master, it will actually push that change up to GitHub. When I set, when I installed these, when I cloned the repository from GitHub, I didn't specify what to name the remote repository. And by default, Git will use origin to reference the remote repository. You can set it up to use other terms. I've got our actual Drupal repository. I have a copy of it on GitHub, but I've got another copy that is through our hosting provider. And so I actually have multiple remote in that repository, and I can push to either or both. But by default, origin is going to be the default. And if you're using the client, you really don't have to worry about that. But now if I go back to GitHub, and I can do a pull request, not a pull request, but I could sync it, it will tell me that I did something really wrong and deleted a file I shouldn't have. And now I've got a conflict. If what I had done was just to create my own new repository where there was no remote on GitHub, and I wanted to push it later, I can use Git remote ad to identify it. So if I were doing origin master, I would do Git remote ad origin and then my GitHub URL. And then that would allow me to push a brand new repository up to GitHub just by saying Git push origin master. It won't get pushed or how you pull a change. In the GitHub client, it's just synced. It doesn't distinguish between pulls and pushes. It's going to do both in either all the time. Because if there are six changes that have been made in another repository and pushed up to GitHub, and you try to push your changes up, it will tell you that you need to pull your changes down first and with the sync button, it just sort of takes care of all of that for you. Keeping track of things, Git has a few very useful little commands. Git help or Git help command will actually tell you how to do things in Git. I don't know if that exists in all of the clients. It does exist in the command line. And anytime you install the client, it's going to install command line tools for you. So you can always use the command line to say, get help on commit. And it actually opens the Git manual. Git status, which I just did, will show you the status of whatever is in your working directory. In this case, it's clean. If I made changes, it would tell me if there were changes that are ready to be added. It would tell me if I had untracked files and that kind of thing. Git log will show you what's been done. It exists in the Git clients as well. I can see every change that has been made since the beginning of this repository. Or I can see it here on the command line. Git diff. If I have changes that are sort of a staging environment, so I'm just going to edit real quick this file again. And if I do Git diff, here it will actually tell. Git is also very helpful in telling you when you did the type sense right. And I'm not sure why. Now it will tell me that I modified this file. And if I do Git diff, it will actually show me that I deleted the line it's Tuesday and added the line it's Tuesday, June 13. That's useful for being able to see what has been done in code. Those commands will get you 90% of the way into using Git. With just those commands, you should be able to create a Git repository, pull down an existing Git repository, add files, commit files, and then sync between the remote repository and your local instance. Now I'm going to talk about a few more advanced concepts. By default, everything that you do in Git is in the master branch, unless you change things. Git allows you to create as many branches as you want in your local repository. Let's see something for the scary. I should have said a minute. What this allows you to do by using branches allows you to keep your master branch clean of things that aren't ready to go up on your production website. If I'm working on a major feature, I don't want bits and pieces of that up on the production site until it's done. And so what we can do is create a new branch called featureX, do all of the work there, and then when it's really done, commit it to the master branch and put that master branch up on my production site. That is a really, really handy way to allow you to keep working on the website without messing up anything that's live on the website. It also prevents a problem that we've had by doing so much in the master branch on our current website. Sorry, I can't make that teeny tiny fix for you for another month, because I've got this major, major fix sitting in the master branch. And if I push your chain jump with this stuff not being done, it's going to break the entire website. By using multiple branches in our case, we use a branch for every feature that we're working on. We don't have that problem. I can finish a small feature and commit that to production while working on massively large features in another branch, completely independent of a smaller change. I just pulled up just there's a command called get branch. And this is actually what is running right now on Aleo's, on my local copy of our Drupal website. I have about 25 open feature branches that are in a state of not being done before they get completely committed to our new website. So get will let you have as many of these features as you want, whether you should or not. And GitHub is really easy. Widget here is your branches. I can add it's not the most intuitive thing here. Or on GitHub, but if I just start typing develop, it should actually create a new branch. Develop and I want it from the master branch. It should create a new branch for me. And now any work that I do, any changes that I make are being made in this particular branch and not being mixed up with the production code until I tell it it's done. And I can switch back and forth. I can do all those same things on the command line just by using create a branch, get branch to the branch name. I can delete it by using the slash D tag. And I can merge it with the master branch just by saying get merge master and whatever my new branch name is. Adds are another option. It's essentially a branch that you can't change. And what it basically does is says this tag represents a snapshot of our code at a particular time. This allows us to essentially tag releases, version point 2, version 1, and allows us to, let's say we push version 1 up and realize that we really shouldn't have done that yet. I can go back and say, OK, I've got version point 9. I'm just going to make that the live version and then all this version 1 point stuff goes away. It's a useful tool for keeping track of the launch of major code changes. And I'm less familiar with how Git handles that. I'm not quite sure how to do it in the GitHub plan. All I did was create a tag named hello. And apparently there's already a first tag and second tag already created. And now if what I wanted to do was to push up to our live site, the tag hello, I would just do git, push, origin, hello. And it's going to actually create that as a tag on GitHub. One of the best reasons for using Git is to undo things that are wrong. This applies not just for Drupal custom modules, but also for Drupal contributed and core updates. Because what happens, particularly depending on the more contributed modules you add to your website, the more likely that when you install a security update, something is going to break. Because all those core updates aren't always tested against the thousands of contributed modules that are out there. Or somebody could have made a patch to a contributed module that you've just upgraded that turns out to break something else. We use both the date module and the event registration module. And changes to the date module have been done to break the event registration module. So being able to revert my changes, let's say I did all of my core updates in one commit, turned out I pushed it up to the website. I look at the website and all I have is a white screen, which in the PHP and Drupal community is known as the white screen of death. I can do get revert and that commit and wipe the whole thing out and go back to what I had before and hopefully can run a local instance of Drupal and try to pin pull of my website and try to pinpoint exactly who broke what and look and see if somebody has created a patch forward or if I can patch it myself. Or if I just need to hold it, put the updates on hold until a patch is released. So being able to use get is useful if you want to interact with services like GitHub and Bitbucket. Not only can you use GitHub and Bitbucket for hosting your own projects, but you can use them to borrow other people's code. So what are GitHub and Bitbucket? They are cloud hosted repositories. They both support public and private repositories, which public repositories anybody can access, anybody can make a copy of, do whatever they want with it. And if they want, they can share those changes back and give you the option to accept their changes or not. Private repositories are ones that are not accessible to people who are not given explicit access. In addition to hosting repositories on what makes both GitHub and Bitbucket attractive are that they offer these additional tools of issue tracking, Wikis, a nice user interface, and also a series of web hooks and service systems that, from the development side, allows us to do some additional fancy integration with other tools. For example, there is a web hook on both platforms that would allow me to, as soon as somebody pushes a commit up to a repository, send a Slack bot notice to everyone on our development team saying, this has just been updated. The key differences between the two, GitHub works really well with the GitHub client and Bitbucket works really well with the Source Tree client. They are both free for public repositories. They both want to host open source code. Gwen, are you back on slides at this point? Yeah. We are just seeing still the command line stuff. You're only seeing what? Look, now we're seeing the slides. OK. Excellent. All right. Sorry about that. No problem. They're both free for public repositories. Bitbucket is free as long as your team is less than five people for private repositories. GitHub charges for private repositories, although I just noticed yesterday that they also offer non-profit pricing, which is basically free. Well, actually, it is free as long as you sign up for an account and then send in the paperwork. GitHub is the home of many open source projects, including D-Law, which is the Drupal legal aid website library, or Drupal project. If you use Q&A Markup, that's available on GitHub. They learn the law classroom modules that were created for private. They're Connecticut, or also on GitHub, and Jonathan Pyle out of Pennsylvania's doc assemble module code is all on GitHub, which means we can all go to GitHub and download, create our own copy of this code, and make changes to it and improve upon it. So I'm going to actually do a quick tour of both GitHub and Bitbucket. And to show GitHub, I'm actually going to use the repository for Aleo's current website in ColdFusion, because we have a lot of it. We use this for several years, and there's a lot there. And it is a private repository. From here, I can see all of the files that exist on our website. I can see every change that has ever been made to individual files. I can see exactly what was changed on the individual file. And that's all great. I'm going to do the same thing on the desktop client. But where GitHub really is useful is on the issue tracking. We use some outside developers. We're not all in the same location. So we use the issue tracking system to keep track of what needs to be fixed and what the status is. Next, I can assign it to anybody on our team. I can associate it with a milestone if we had milestones defined. I can give it a label. So this is what's called a code improvement. And now Terry is going to get an email telling her that she has a new issue on GitHub. She can get that in her email. She can't reply in all of the replies and all of the conversation that happens with the issue, even if it's being done over email, automatically comes back to here and creates living documentation. When we have different developers working on things, I don't normally let them commit their code directly. I want to look at it first. And so GitHub allows us to create pull requests that show the changes that have been made. And then I can review the pull requests and then merge it with our code base. There's also a wiki, which is useful if we want to put documentation up. And there's just some little widgets and gadgets that says, here's how active you've been. Our current website is not getting a lot of work being done because we're working on the new site. So there's not really activity. There's some graphics. Here's where we started on the new website and clearly it's been limited activity since then. I can see who is on our team. And we can have multiple code repositories. So I've got one for that. I've got one that's got a copy of our Drupal website. I've got some old ones for when we had, but we're still working on our iOS apps. And it's really pretty easy to use. I have not worked as much with Bitbucket as I have with GitHub, although that may change because we use some other Alasian products. But it's very similar in concept. You have a repository. I can see the history. I can see the different branches that may exist. It has the same sort of issue queue. It also integrates with Alasian's JIRA product, which we use for all of our technical issue tracking. You can integrate it with GitHub. It just takes a little bit more work. And this is seamless. So for the issues, where's the ad button? Create Issue. And it's the same sort of thing. Put a title, a description, a sign into somebody, and create it. The only thing that I can't do in Bitbucket that I can do in GitHub is assign labels to it. It's also got a wiki. So I can add documentation pages here. I can download the full copy of the repository, which I can also do on GitHub. And I'm actually going to skip over these since I was able to actually do a live demo this time. Both GitHub and Bitbucket are good platforms for hosting remote repositories. I've become comfortable using either one in a lay-offs environment and have been using GitHub for several years. To learn more about GitHub in the Cloud, GitHub in the Cloud is a tutorial that will actually walk you through and teach you GitHub in about 15 minutes. There's a Git cheat sheet that will basically all of the basic commands in a nice little PDF. Git workflows is a document that allows you to empathize. In addition to using everything in the master branch or just randomly creating branches, there are some specific workflows that exist to work with Git. The development methodologies. We use one here called Gitflow, which is pretty popular in the Git community, that forces us to use feature branches for everything. And then anything that's in a feature branch is eventually through the develop branch. And all of our releases on our production server are tags off of the master branch. And we never actually put the master branch into production. But those are just some things that if you're going to go down the Git path are worth looking at. We didn't use that until our Drupal project. Our current website is everything is pretty much in the master branch. We have a few project branches from when we were doing big projects. And everything that comes into the master branch, I have to review via pull request. Once the recording is done, the slides will be uploaded along with it on Alison Tab's YouTube channel. And that is my Git presentation. Thank you so much for putting this on, Glenn. A lot of useful tips in there and just the features that are available online for version control, that type of stuff, have just gotten so much better in the last few years. Yeah, when I started doing development, I did everything as source safe. And then we moved to some version. And it was all still locally hosted. And then GitHub really came along. And as long as you weren't on Windows, it was great. Because it took them a long time to release their Windows client.