What do you want to learn? Leverged jhuang@tampa.cgsinc.com Skip to main content Pluralsight uses cookies.Learn more about your privacy GitHub for Windows Developers by Brendan Enrick This course shows developers how to effectively use GitHub, Git, and GitHub for Windows. Start CourseBookmarkAdd to Channel Table of contents Description Transcript Exercise files Discussion Learning Check Recommended Brief Introduction to Git Introduction Hello. This is Brendan Enrick with Pluralsight. Welcome to my course on GitHub for Windows Developers. In this first module, I will briefly introduce Git for those who aren't already familiar with Git. In later modules, we'll move into the concepts that are specific to this course's namesake, GitHub. In this module, I will begin by explaining what the Git version control system is. I'll cover very briefly the history of Git so that you understand why it works the way it does. I will then review differences between the classic centralized version control systems and the newer distributed version control systems. Finally, I will show the command line version of Git, but not extensively, just enough so that you have an idea of what's going on beneath the surface. For more details on the command line version, you can watch James Kovacs course, Git Fundamentals. About Git The first question we'll be tackling is what is Git? Well, odds are that you've heard of Git, or at least heard mention of it before, that is why you're watching this course after all, and depending on how you heard of Git though, you might also be asking why would I want to use Git? And these are both easy enough questions to answer. At the most basic level, Git is version control, or a source control system much like any other source control system you've used before. It will track your changes and allow you to commit changes to a source control repository. These systems are designed to facilitate collaboration among a group of developers working in the same code base. Git, however, is a modern distributed version control system. This makes Git a bit different from most traditional version control systems. I will be explaining some of these differences as we talk about some advantageous scenarios in Git. As a distributed system, Git focuses a lot on branching and merging. It also has two additional concepts called pushing and pulling, which are distinct from the committing and updating that you're most likely used to. Committing is still central to Git though, but these commits occur locally and need to be pushed out, and we'll be talking about examples of these and seeing some of that later in the module. Coming from the open source community, it was very important that Git be very fast by using local commits. It needed to scale from very small to very large software projects, and with the number of developers involved in some of these large projects, it needed to be distributed and it was important that the system be very parallelized, and overall, it's really a system that's designed around creating collaboration in situations where collaboration would otherwise be a great challenge. So that is why we use Git. And now for a little bit of the history of the Git project. Git is a relatively modern version control system. It was created in 2005 after a series of events made its creation necessary. For a few years prior to the start of the Git project, the Linux kernel was using a proprietary distributed version control system called BitKeeper. When the relationship between BitKeeper and the Linux Kernel Development Team fell apart, the company who owned BitKeeper no longer offered a free-to-use license. It was at this moment that the Linux kernel required a new distributed version control system to replace the old one. This requirement is why Git was created. Linux developers, as they're known to do, began reinventing the wheel and creating a new simple version control system to manage the kernel. This new system they were designing was created to be fast, fully distributed, simple, highly parallel, and scalable enough to handle the largest and smallest of software projects. Since 2005, Git has been growing, changing, and increasing in popularity. An entire ecosystem has formed to support the needs of Git's users through hosted solutions, productivity tools, show integrations, and much more. This growing ecosystem is actually why you're here watching my course on one of the strongest entities in the growing community, GitHub. CVC versus DVC So before we discuss the distributed nature of Git, I'd like to remind you of the centralized structure you're likely using now. If you're already using Subversion, CVS, TFS or any other mainstream versioning system, you're used to this model already. With it, each developer works on his or her own computer and makes commits to a central server that is managing all of the code. Notice in this illustration that each developer receives updates directly from the server and sends updates directly to the server. This is a simplification of the process, but it illustrates how most developers work with source control today. So now we're going to take a look at the distributed version control model. The first thing you need to know about a distributed version control system is how the distribution works. In this scenario, everyone has their own personal source control repository. In this illustration, that repository is represented by the folder that's displayed next to the laptop. Your personal source control repository means that your commits are local. Each time you commit, you're storing a new version of the code in your local repository. This makes it easy to commit frequently since you're worrying less about the impact on other developers. You can instead focus on making sure that you commit as often as possible. Once you've gotten your code to the point where it's ready for others to consume, you can push those changes out for other people to access. This is sort of like the committing that you did in the centralized version control system in that this is the point where you take the code that's on your machine and send it up for others to be able to consume. Now that you have the basic concept of how distributed version control works, I'd like to show you the interactions of that distribution. The first thing you'll notice is that there are a lot more options than we had before. In fact, any of the repositories shown in this diagram can push or pull from any other repository. Don't worry though, you don't have to change your process. Most teams and most workflows still focus primarily on the traditional structure. You'll notice, it's still here. At this point, I'm sure you're wondering how this more complex model can make your life easier. Let's use an example. We'll look at two developers, Brendan and Steve. These two are working together on a feature, and Steve's code is depending on some of the code that Brendan is working on. Since Brendan is not done with his feature, he has only been committing locally. Steve, however, would like to put some effort into his code and see how well it's going to integrate with Brendan's code. So Steve pulls the code from Brendan's repository instead of the central one. When Brendan finishes his code, he pushes it to the central repository. Then, Steve is able to pull the final version of Brendan's code from the central repository. Since he was already using the code, he is able to finish his task, commit locally, and then he can push his changes back to the central repository. When Steve does the merge, he will not have complex merging to deal with like he would have done if he'd done this with a centralized versioning system that wasn't keeping track very closely of change sets. The reason for this is that Steve had Brendan's changes already when he was writing his code, so the server knows that the code that Steve was working with is the same code that Brendan pushed, and not just code affecting the same files. The unique ID of Brendan's change set allowed all this to happen. Basic Git Commands As we talk about Git, it's important to remember that Git was originally created not as a graphical tool, but as a command line tool. Because of this, a lot of the commands in the workflow for Git were set up with the idea that you would be using a command line utility. This is similar to a lot of other version control systems I'm sure you've used. As we'll be doing a brief demonstration of the command line version of Git, I thought I'd start by explaining a few of the commands that exist in Git so that you will recognize them and understand what they're doing as we quickly go through a demo. The first one is init. That's used to create a repository. The second one here is status. That lets you know what the current state of your local repository is. It doesn't show you if you have anything that's committed, but not pushed, but it will show you your noncommitted changes, as well as anything that's staged. The add command is used to add files to the repository, as well as a few other tasks. Committing is how you make commits to your local repository. When you commit, that's making a save of the current working directory of your repository. Log is how you see those changes that have been committed. Push is the command to push your changes that you have committed locally up to the central repository that's configurable and can actually go to multiple locations. Pull is how you pull changes down from another repository. This is also configurable. In fact, you can point to more than one origin that you want to pull from. This is not supported in GitHub for Windows yet, but is in the command line. Merge is the command that you use when you need to merge changes that have come in from separate places, or separate branches, or in any way you have two pieces of code that need to be merged together. Command Line Demo Now that we understand a little bit about Git, it's time we took a look at the command line version of it. This is going to be important as we learn GitHub for Windows, because all of the commands that happen in GitHub for Windows match with the commands that we're using in the Git command line. So GitHub for Windows is doing all these operations behind the scenes for us. You'll notice here that I've opened up the Git command line. For this command line, I've used the PowerShell version of the Git command line tool. I'll show you later how we can open up this tool and use it. The Git repository that we're going to be connected to is one that I've already set up on GitHub. I'll show you in the next module how you can set up one of these repositories for yourself so that you'll be able to use this technique to access it. So what we're going to want to do is begin by getting ourselves an instance of the remote repository that I've set up already that's on GitHub. The way we're going to do that is by using the clone command, and we're going to specify the address of that repository. This command is just git clone followed by that URL there, which you can find on GitHub. When I run this, it's going to pull the data down and unpack it and I will have a local copy of that repository. Now I have a local copy of this repository. The next thing we'll want to do is go into that repository and start working with it. So now that we've navigated into that repository, you can see that the command line has changed a little bit. It now has this master written in there. That is because we are actually inside of a Git repository at this time, and you'll see that it's going to be giving us a lot of information as we start working with Git. So, the first thing we're going to want to do in this demo is to create a file so that we can see how the file creation process works. So, now we have a file called AboutBrendan. So if we take a look at the directory, you can see here that we have a few files, including that one we just created. You'll also notice that the command line changed a little bit, it now says master and includes some numbers, as well as it has used the color red. This indicates that we've got some changes that we haven't told Git about yet, and it would like to know what they are. So, we're going to go ahead and add that file to the repository so that it knows about it. So now you'll see that the command line actually changed here, this is because we have this new file. At this point, we can take a look and see the status of our current repository. You'll see here that it knows about that new file and that we have changes that are ready to be committed. So let's go ahead and commit those now. I'm going to commit this now, and I'm going to use the --m parameter, which is going to allow me to specify a message along with my commit. So, now we have committed, just like we would have in any other source control system. This saves our files in the version control. Now keep in mind the difference here is that these files are still local to this computer. We have not sent any files out anywhere else. You'll also notice that the little command line changed a little bit. You'll notice some color changes, as well as some numbers disappearing. So while before we had uncommitted changes and it was telling us about those, we no longer have uncommitted changes, so the numbers are gone, and our word master has also changed colors. Let me show you why. So now that we've pushed the changes, you'll see that master changed again. The color was indicating that we had changes local on our computer that hadn't been pushed out yet. That's really useful because now we know whether or not we've forgotten to send anything up. There are visual indications like these inside GitHub for Windows also that will let you know whether or not you have synchronized your data, and will allow you to do that. So the next thing that we want to take a look at is we'll take a look at our status at this point. You can see now, since we've committed everything there's nothing to commit, and our working directory is clean. So now if we open up a file and make a change, we'll see some differences. Now you can see that we can open this file and make some modifications. Once we've made these, we can go ahead and save the file. Now that we're back in the command line, if we take a look at the status of things, you can see that we have a modified file. Now you'll notice that everything is red. This is because we don't have any staged commits. If we want to stage that file, that means get it ready to be committed, we can add it. It's also possible to just commit and tell it to include the files that have not been staged. Instead of doing the automatically adding these files while committing, I'm going to take the approach of staging them first, just because that's the approach that I prefer. Now you'll see that things are green again because it's got changes that are ready to be committed because they're staged. So the next thing we're going to do is commit these. Now that we have that commit, we can go ahead and make another change. (Typing) Now we have two changes in that file, let's go ahead and commit this one. So you probably notice that I typed git add before I typed git commit. This is a process called staging, which is essentially getting your changes ready before they are committed. I was not required to do this, but I find it good practice to make sure that I stage all of my files before I commit them. So we can take a look at the log and see what changes we have. You'll see that the first thing we had here is created a file about Brendan. The second thing is added info about Brendan to AboutBrendan, and the third thing is added Pluralsight info, the AboutBrendan, ah, it looks like I typo'd that. Now I'd show you some of the cool features of the command line here, of how we can fix that, but that's something that you should probably watch a course specifically on the command line to find. So I think you probably have a pretty good idea of how you can use commits and pushing to get things done. Now at this point, if we take a look at the GitHub website and look at the repository, you will actually notice that I have not sent up my most recent changes. We're still actually at a blank file for the AboutBrendan.md file. That's because we haven't pushed these changes yet. Now I'm going to go ahead and push these two changes, and those will end up on that site. So now it sent those files up to github.com/BrendanPluralsight/cmd-demo. If you go ahead and take a look at that repository, you'll see it's public and be able to see all of our changes and commit messages there right now. Here you can see that we've got our commits from the recent check in and push that we did before. You'll see here that the commits have messages matching the ones that we typed in, and you'll see that we are on github.com/BrendanPluralsight/cmd-demo. If we want to take a look at the individual file, we can just open this up and you can see there are the changes that we made to our markdown file. We can take a look at the raw version of it here. You'll also notice that it has unique identifiers there. Those are actually so that the system can uniquely identify each one of those commits. In the example we mentioned before, where Brendan and Steve were coordinating, it's that unique ID that made it possible for Git to know that Steve and Brendan were actually working on the same code, and not just two commits that happen to be affecting the same files. It actually knows specifically which commits Steve had pulled into his repository and was working with. That is very powerful. Summary Whether you're just learning about Git, or this module was just a refresher, I hope you've learned a lot about Git and are ready to start learning how you can use GitHub to make your software projects more successful. From this module, you should have a better idea of what a distributed versioning system is, why and how the Git system was created, and how to do some basic work with the Git command line interface. The next module focuses less on Git and more on GitHub, and from there we'll focus on the combination of the two until the end of the course. Thanks for watching, and we'll see you in the next module. Using the GitHub Website Intro to GitHub Hello, and welcome back to my Pluralsight course, GitHub for Windows Developers. I am Brendan Enrick, and in this module we'll be covering the GitHub website. This will give us the chance to see how to set things up and get started using GitHub. As we start wading into this topic, I'll explain a little bit about what GitHub is. From there, we will move into setting up our accounts and repositories. Yes, this module spends a lot of time on the website. Once we get a good look at how to work with and manage our repositories, I'll discuss organizations and accounts in GitHub. I'll be explaining the differences as we move forward from that point. Since software projects often involve collaboration, we'll be looking at how we can manage and organize teams for our projects using GitHub. Along with that, we'll also be covering permissions on repositories since that fits in well with the setup that we're doing already. We'll close this module by discussing issues, comments, wikis, pages, and other information available to us on the GitHub website. Now we're ready to dive in. So, what is GitHub? We've seen Git, it's a distributed version control system, GitHub, however, is a service providing a hosting location for software projects and the source control it uses is Git. So as you could have guessed, it's a hub for hosting Git-based projects. In our sketches in the previous module, the central server, the ones still used in most distributed setups, is GitHub. This means that when we want to push our changes out to the rest of the team, allowing them to pull our changes into their own local repository, we're going to be pushing those to GitHub. As a central location for our projects, GitHub is where we're able to collaborate as a group. Most of our software projects have at least one other person working with us, so it's important to have a place to keep track of things and work together. If you're hosting your Git repository at GitHub, you'll most likely be using GitHub for some of this collaboration as well. For quite a while, GitHub used the slogan Social Coding. This all ties in to the collaboration I was just mentioning. If you'll recall, Git was created by the open source community, clearly that's also the group that adopted it at first. That means that a lot of its use is by open source projects. This social coding concept is all about bringing together social media concepts and software development. It's something that GitHub really embraced, and we'll learn more about it later as we look at gists and some of the other profiles and information that GitHub makes available to us. Last, and certainly not least, is the octocat. Yes, that's important when doing a course on GitHub, I couldn't leave this guy out. You'll notice the octocat all over the place. This is GitHub's mascot you might say. Most of the time you'll see this normal looking guy, but he's been dressed up in all sorts of different outfits. You'll find hints of him on icons and logos all over while using GitHub, so don't be surprised when you come along an interesting octocat or two. The octocat can be found in a variety of different looks by checking out the Octodex, and it contains plenty more than you'll probably ever want to see. I'll show you a few of them now. This is GitHub's Octodex. It contains all kinds of interesting octocats that you can peruse at your leisure. You'll notice quite a few in here. Installing Git Now that we have an account with GitHub, our next step is to install Git. Luckily, on the home page that we get to after signing in, we start off with a set of instructions. There's a link to set up Git. If we go to that link, it's going to open up a new tab that provides instructions for how to install Git. This information, however, is about installing the command line version of Git. It's a bit similar to what we were using before, however, in this module, we're covering GitHub for Windows developers. Toward that end, we're going to be using the graphical user interface application that GitHub provides. It's a native application that runs on Windows that you can use to do all of your Git interactions. We're going to go ahead and download that now. Now that we've got that downloaded, we can go ahead and start the install process. The installer is going to use a standard wizard approach, we can just follow along. At this point, we now have GitHub for Windows installed on our computer. You'll notice I'm not logged in, I don't have any local repositories, there's almost nothing here. We'll be fixing that a little bit by setting up some things in the website, and we'll see how we could do some of these changes locally inside of GitHub for Windows in the next module. For now, we're going to jump back to the website and see how we can set up repositories there. Working With Repositories Now that we're back on the website, let's take a look at a couple of ways that we can set up a new repository. You'll notice on this page that there are in fact two places where we can set up a new repository. The first one, down here, says New repository and has this little icon next to it. You'll see that same icon up at the top of the page, that's also a create new repository icon. Either one of these will work. I'm going to go ahead and click on this one. Now that we're on this view, we can do a few things. The first thing is coming up with a repository name. Normally that's a hard process, but GitHub likes to throw in a little joke one for us, so we can go ahead and fill in this. Next thing we're going to do is decide whether or not we want to have a description. It's an optional field, and for the time being since I don't know what a ducking-octo-meme is, I think I'm going to stick without a description. The third choice we have to make is whether or not we want to make a repository public. This means that it's either going to be open for anyone to get to and see the repository and see everything we've got in there. That doesn't mean they can edit it, that just means they can view it and that we're not restricting that access. If we want to choose Private, we can restrict who is allowed to view the repository, but by doing this, we have to have a paid account if we want to choose the Private option. For now I'm just going to stick with the Public one, and we'll see a little bit more about the private ones and how you can restrict the access later. The next thing on this view is initializing the repository with a README. We're going to want to do that. I'm going to explain a little bit about those later, but go ahead and make sure you create one of those now, because that's going to be the description for your project, the real description, not this one. Last but not least, you want to make sure that you include a gitignore file. This is kind of hidden here, you don't necessarily notice it, and you might glance over it, but it's very important, it's going to make your development a lot easier because this has a list of standard exclusions of different files, and we'll take a look at this, how you can view it, and some ways to customize it later. But for now just go ahead and pick based on your language. I'm going to go ahead and choose CSharp, and it's going to include a gitignore file that has exclusions for different CSharp-based project files. You can also choose a license. At this point, I'm just going to go with None and just move on. And there we go. We now have a repository. Now that we've got this repository set up, let's take a look at some of the options that are available to us. I'm going to first dive in to the Settings. Here you'll notice that we've got a few different settings available to us. The first one here is that we can rename our repository, so we can rename it to whatever we want. If we do this, you'll notice that it tells you exactly what it's going to be naming it to, sort of gives you a visual indication, and if you click on Rename, it'll actually do the rename. I'm not going to do that just yet. You can also make another few changes. One of them is you can change which branch is the default branch, so anyone that comes to your repository is going to start out on that one. So if you want to change up your process a little bit, this is a way to make sure that people start in the right place. There are a number of features that come with repositories. One of them is the concept of having a wiki. This is a great way for people to be able to contribute content, have discussions, and be able to edit pages that you might use later for documentation or support, there are a lot of ways you can go with this. So it's a convenient feature that you can just use if and how you want to use it. You can also make sure that your wikis are only able to be edited by your collaborators, so if you don't want other people to be able to contribute to the discussions, you can lock that down. Issues are one of the ways that people can let you know about problems they have or feature requests or other things that they'd like to see added in to your project. It's a pretty lightweight way of handling things. This gives you a little bit of project management inside of GitHub. That doesn't mean you can't use your own project management, and the issues in GitHub actually can work with some of the other project management tools out there. A lot of them will actually tie in and pull the issues out of GitHub so that you can synchronize between the two systems. One final feature that we've got that is a very interesting and useful one is GitHub Pages. This lets you create pages for your site. So if you want to have more than just your GitHub repository, if you actually want to have a site that's hosted about your project, you can do that right through GitHub, and it doesn't cost you anything more. The way it works is you just push and HTML site to a branch named gh-pages. You can also use the automatic page generator that's built in here. I'm not going to be covering that right now, but the automatic page generator is an easy tool that gives you a WYSIWYG editor to create your pages. So if you don't want to spend a lot of time setting up your pages for your repository, you can go ahead and do that, and that'll let you get some intro and overview and about pages set up so that people can read a little bit more about your project. And it's nice because it's all stored in source control and easily modifiable. The last part you'll notice is called the Danger Zone. These are all of the aspects of the settings that you can change that'll have a significant impact. The first one is to make your repository private. Since I don't have a paid account that I'm demonstrating this with, you'll notice that it's suggesting that I upgrade my plan. If I upgrade to a paid account and I can get one of the really cheap accounts, I could get a private repository, and there would be a button on the right that would allow me to create a private repository. Another operation I can do is transfer ownership. This comes up a lot when you want to transfer to an organization from something you've started yourself. It happens, you might also just be transferring to another user, so if you're tired of being the person that is maintaining a project, you can pass it to someone else. When you do a transfer, it's actually going to prompt you to type in the name of your repository and the new owner, and the reason that they do this is so that you're very certain that you're transferring the correct repository. This is a little bit harder of a barrier than just a confirmation box, but it prevents you from making a mistake that you might regret, and it gives you a lot of information about what's actually going to happen. This is actually the same style of thing that it does for deleting a repository, because once you delete it, it's gone, it's off the GitHub website. You might still have some local copies of the files and the repositories, but GitHub has forgotten about it. So if you had any wikis, issues or comments or you had branches that people didn't have polled locally anymore, you might run into some problems. So be careful here if you're deleting your repository. They make you type in the name of the repository as confirmation, so it's hard to accidentally do this. And that's pretty much it for the settings you have access to in GitHub. README, .gitignore, and Live Editing The last things I want to show about how you can work with your GitHub repository are a few things. I want to make sure that I cover how the README file works, so we're going to start off by taking a look at that. The README file here, you'll notice is a file that actually got created in my repository. It's a README.md file. That .md file is a Markdown file. This is useful because it's actually going to be editable inside of source control in Git. What we're going to do is we're going to go ahead and modify this to add a little bit of a description about our project. (Typing) When we take a look at the modifications we just made, you can see in this preview that we've got some headings, some smaller headings, and we have a lot of control over what comes up here. This is important because of one thing. We're going to go ahead and save this now. Notice here that I have a Commit summary window. Here I'm going to say Added some information to the readme. Now when I click Commit, if we check the history of this repository, you will actually see that we have made a modification. You can see here the most recent commit is Added some information to the readme. You can also see now that when we're on the main page of the repository, that README appears here. So this is the first information that people see about this, so it's very important. Let's take a look at our commits. We have the initial commit, which is the one that was set up when we created our repository, and we now also have that we added some information to the README. That's really awesome. The next thing I want to show is this .gitignore file. You'll notice this is also in source control. We created this before because this has patterns that describe different parts of our projects, different files that we want to exclude. You'll notice in here that some of the build folders, the bin and object folders are being excluded. They're listed in here because these are the ones that are not supposed to get checked in. So these are all the files that you actually build. Clearly we just need the source code because anybody that gets the source code could build these files. You'll notice that we're not excluding the dll files. That's because those are the files that are occasionally used as references that we might want to include, so it's doing folder exclusions instead. It's also getting rid of user-specific files and some other files that are common in Visual Studio C# projects. Remember, we picked C# as our language, so that's why all of these have to do with C#. We could also edit right here, or edit it in our regular source control workflow. Either way works just fine. The last thing that we want to take a look at, that I really want to show, it's very powerful, is this Clone in Desktop button. So, cloning is the process of getting your local repository. So remember, with a distributed version control system, we have our own local repository. This server at GitHub also has a repository. The reason it's called cloning is because we're just getting a copy of the one that they're using, and we're going to work with that one locally. So now I'm going to click this button and we're going to see what happens. So now I'm presented with the option to login. I'm going to go ahead and login with that user account now. And now you'll notice it automatically went and cloned that repository and got me an instance of it. You can see our commit histories there, my user account is the one that we're logged in with, and everything's been setup and working. So you'll notice I just clicked a button on the website and immediately I've got a local copy. That is one of the most convenient features in GitHub. If you're not using it, you really should be. Organizations, Teams, and Collaborators So the next thing we're going to cover is the concept of an organization and an account. In GitHub, we have both accounts and organizations. An account is generally associated with an individual user. What we created when we went to the GitHub website is an account. An account is essentially one person, they can own repositories, they can be active on any number of repositories they want, they have their own profile, and they can use this site to get a lot of work done. Alternatively, a repository, instead of belonging to an account, could be part of an organization. One example of an organization on the GitHub website is, well, GitHub itself. They do a lot of their own development on GitHub, duh, and as part of that, they have a lot of their code right here. And you can see that they've got a number of members in the system. And those people are all accounts. You'll notice though that this organization has a whole bunch of repositories of its own. So that's one of the places that you could do this. So, I sort of want to cover really quickly how you can either create an organization or convert your account into an organization. So if you set up an account for maybe your own personal things, but then it picked up and you want to now turn it into an organization, or perhaps you created your company's organization at first as an account and you have a bunch of repositories associated with it and now you want to open it up for better collaboration. However you got into this situation, it's pretty easy to do. Let's take a look. From this page, we can go to Account settings, and that's going to bring up some information about our account. Some of this is self-explanatory, but we're going to go ahead down to this Organizations section. Once we're here, you can see that I'm not currently a member of any organizations, but I'm presented with the options to create a new one or turn my account into an organization. Since I don't want to do the latter, I'm going to do the former. In order to set up an organization, all you have to do is go through, create a name, it's going to be hosted at the same type of place that an account would, it's just going to be github/, and then the organization name instead of an account name. You'll set up a billing email so that they know where to send the billing, and you choose which level you want to be working with. If you're open source, you can go ahead and choose the free plan, but if you're a company, they have a number of other plans that will allow you to have private repositories. Once you create your organization, you'll be able to use it for a lot of different purposes. (Typing) Now that we've gotten this set up, we have set up our owners. Now this is a very important concept in GitHub. Owners actually have special privileges, more than what a normal member of the organization have. The owner is actually able to modify the billing information, so be very careful about who you give access as an owner. They also have complete access to all repositories and all information about the organization, regardless of individual permissions. Each owner is fully an admin in GitHub. If you want to be more limiting in what access you give to people, you should put them into teams and modify those permissions. So be careful about who you put in the owners. For now, I'm going to go ahead and just stick with having that one demo user be in the owners group and not add anyone else. So now we've been setup with an organization. We can actually create repositories here, and our user account can get access to it. The other cool features that we get now are we can actually choose which account we want to be working on. So we can either be on our user or on our organization, and we can create a new repository in either one. You'll notice now on the new repository window, I can actually choose whether I want to create a repository for either myself or a repository for the organization, I get the option. It's quite nice. So now, every time I go to this page, I can choose whether I want to be my user or on the organization. You'll also see once you get them a list of the repositories that belong to this organization. So that's pretty much all we need to cover about how organizations work. We'll talk more about them later, and they're going to come up as we start diving into things, especially as we get into collaboration, social coding, and other workflows. So now that we've seen how to set up organizations and what the difference is between an organization and an account, I want to show a little bit about how we can work with collaborators and members of projects, and deal with teams and permissions and take a look at a lot of those different options that we have available to us. Behind the scenes, I went ahead and created a repository in the organization as well. That way we have a repository in the organization and also in our user account so that we can look at both styles of user permissions and collaboration. I'll start out by showing how collaboration works in a user account. So let's go ahead and switch from the organization over to our user account. When we do this, we're going to go ahead and open up that repository. From here, you can see that we have one contributor. Right now, the only contributor is PluralsightDemoUser. In order to change that, we need to go ahead and add another one. So what we're going to do is we're going to go ahead and open up the project settings. From here, we're going to click on Collaborators. Sometimes it wants you to confirm your password before you continue on. So now we can manage our collaborators. I'm going to go ahead and add a friend of mine. So now that I've added myself to this project, I now have a collaborator. That collaborator is allowed to edit this project. Since we're just working with an account, this is pretty basic access that he gets. I can also add another one. So it's pretty easy to go ahead and add yourself to these projects. Once you click the Add button, it's done, there's no saving required, and so far those other two are not contributors, but if they go ahead and make a commit, they will be included in here as well, but they should have access to everything at this time. So the next thing we're going to do is take a look at how to set this up with an organization instead. Let's go ahead and switch. If we jump back to our organization, we can now open up this new repository that we created. You'll notice there's a little bit less information here than there was before. We can go ahead and add ourselves some team members. So if we were to go to the same place we were before and look at Collaborators, you'll notice that we now have the option to Choose a team. The Owners Team is already listed here, so since this user account that we're logged in with is an owner, we have access to modify these. Right now there are no other teams, so we need to go create one. To do that, we go back to the organization. If you click on that, you go to the organization public page, whereas I want to go to the back-end one. So here I'm going to go ahead and click on this little Home button and it's going to take me back to the back-end version of the organization. From here you'll see Teams. We currently have the Owners Team, which has our one user account in it, but if we want to instead go to a new team that has different permissions than the full admin rights of the owner, we're going to go ahead and create a new one. To do that, we decide on the name of the group, so we might call them the DeveloperTeam1 for lack of a better name. The next thing, and this might be a little bit confusing, is that you decide what type of permission to grant. Now notice we're on the organization here, not on the project, that's why it's a little bit weird. So we can decide what type of permission we want to give to this team. For now let's go ahead and say Push and Pull, that is essentially read and write access to the project. We then need to decide who the members are. We're going to go ahead and add one of my other accounts. So if we add this account, it's now a member of this team. This team can be saved, and it currently has access to no projects. So if we take a look, that team is here and has no repositories. We can add our other repository. So you'll see the ducking-octo-lama here. If we add that project, now all of a sudden this account has access to this repository with push and pull permissions. It's a little bit strange because we're doing this at the level of the organization and not at the project. So if we save this, that permission is now there. So you'll notice one user with push and pull access to 1 repository. If I remove that and go to that repository, we're going to go and save, and take a look at the repository, and if we look at the current Collaborators, you'll notice that because we removed it, there are no extra teams, but we could choose this team and add them from here. So now what's strange here is when we're adding based on the project, you'll notice we have no control over the amount of access they get, so make sure when you're doing this type of thing that you're actually going to the teams page and confirming what type of access you're giving. And there's a little shortcut you can click on. If you click on the team that you've just added, you can confirm what type of permission they have. Now remember, this goes for all of the projects, every repository. So if you notice that they've got too much access for your repository, you can't just put them down because they might need push access somewhere else. So keep in mind that if you do need to do that, you can create a second account. So if ducking-octo-lama needs a special team, so we might say the, so the ducking-octo-lama stakeholders might be the name of a group, and we don't want our stakeholders with push access, so instead we're just going to give them pull access. These are the people that are interested in the project, but not the ones that are going to be making the changes. So we can add members here. And so once we add those and save that, we've now given pull access to this group. So if you're in the DeveloperTeam you'll get pull and push, if you're in the stakeholders team, you'll get just pull access. So sometimes you have to do a little bit more than you want, sometimes it's easier this way, just make sure that you know how it's working and you'll do just fine. So the last thing I want to show while we're talking about organizations and permissions is what you do when you want to remove someone. This is pretty important in case someone leaves your Dev Team and you want to make sure that you get them off the team. There are a couple of ways you can do this. If an entire team leaves and you want to remove that entire permission, you can click on the Remove button and that'll remove them from any repositories that they have access to. The next thing you can do is go into any one of these and individually remove the user. So if I click remove here and click Save, that user has lost his permission. I'm going to go ahead and put it back for now so I can show the next demo. So if I go ahead and put that account back on here and click Save again, and we take a look at the teams, I'm in two different spots. Imagine if we had a ton of teams, it would take a while to go through each one and make sure that account is gone. So the way that we can do that is the account settings of the organization. So what we do is we go up to Account settings. If we switch down here, we switch from the user account settings to the organization settings. If we take a look at Members, you'll see that this lists everyone who has access through any of the teams. If we click on Remove here, this'll go ahead and remove that account entirely from the organization. So now that it's gone, if we go ahead back to the organization and take a look at our Teams, you'll see that that user is gone from this one, and gone from this one. So if you ever need to remove someone entirely, completely eliminate their access, that's how you do it. Issues, Wikis, and Pages So there's a lot of information that we're able to store on the GitHub website. I mentioned it to you when we were setting our features. There are wikis and issues and pages and a number of other things that we have access to. When we use these, we can go ahead and take a look at say the Issues. If you want to track your work, bugs or stories or whatever, inside of GitHub, you do that by creating an issue. Since we have none, I can click this button here. If we did, we'd have a list and I could click this one here. Once we have this, you can name these however you like, use a style that uses more of a story notation, use tasks, whatever your workflow calls for, just go ahead and create them. So I might have, (Typing) so I might have this story that I set up that sort of describes a bug. In this one, it's clearly a bug, so I'm going to go ahead and add a label. We're going to say it's a bug. Currently no one is assigned to it, but we could pick someone. We have no milestones that this is associated with, so we're going to go ahead and just Submit the issue. Once we've done that, you'll notice it has this label associated with it. There are a few things we could do at this point. We could edit it, we could write a comment to it, so I could say, (Typing) I could maybe followup asking for more information, and I can click Comment and it's going to go ahead and put that in there. And now someone else can get back to that and hopefully get me some more information. I could of course comment myself, or I could login with another user account that is a collaborator on this project and ask for it. If this were a public project, we could also go ahead and do issues on that one also if they were allowed. Some other things that we can do; if I am watching this, I am getting emails about this. Because we're getting emails on this, we can actually respond to those emails. Now since I didn't set up an email account and I'm not going to jump into one on my own, I'm not going to show you that, but you can, I promise you, just reply to that email and it will end up here as a comment on this issue. So you can mess with comments that way. So if you want to respond back with information, you don't have to login to GitHub, you can just respond to the email by just hitting the Reply button on the automated emails that you get, and that's because I'm watching this post. If I were to assign this to myself, now you'll see that my user account tis assigned, that would also cause that user account, as long as it were configured with the notifications, to get that email. At this point, I could, since I said in this comment here where did you see it, I could say now that it's gone and I can't find it anymore. And this point, I could Close and Comment. So I leave a comment and close out the issue. So now it's done and there's nothing to worry about. You could also use labels. You could use them for your workflow, you could use them for all kinds of things. You can add additional labels if you need to. So you'll notice that there are a few in here already that we'll cover sort of how things work. So if someone creates an issue for you, you might tag that one as a question, or as a feature enhancement, and if someone puts one in that you find isn't really there, you could tag it as invalid. So this one, I said it turns out that it wasn't actually spelled correctly and maybe something weird was going on, but either way we're going to go ahead and mark it as invalid because it doesn't matter. It also might be that, well, this person was looking for British English and we had U.S. English, so we might say wontfix on this or something like that, because we're not going to change it from one or the other, and so there are a number of ways that we can use labels to take care of a lot of the stuff we're working on. The next thing we're going to take a look at are the wikis. So if we open our Wiki, you'll see that we don't have any pages yet. That's because we just started it. If we create a page, it works like any other wiki page. (Typing) So once we've got some content in there, we can go ahead and say a message, Save, it works likes any other wiki. In this case, we're using Markdown as the editing language for it. That's just because Markdown is the default markup language for GitHub. If we go ahead and edit the page, this works just like it does in any other wiki, and we can go ahead and just make any change that we want here. So once we do this, we can go ahead and make our changes just like we would in any other wiki, and it's modifying it and it's keeping our history. So you'll see that this is modifying all by itself as a wiki page, and that's pretty much how the wikis work here. Let's go ahead and view this. Last, but certainly not least, I'd like to take a minute to talk about pages. We discussed them a little bit before, but pages are a really cool thing in GitHub. It's any easy way for you to get set up with some site pages that are the public face of your project, and you can set them up as HTML pages. Let's go ahead and take a look at those. For now we're going to go into the Settings and you'll see Automatic Page Generator. I'm going to go ahead and click on that. Here you can see I've got a project name, and this is sort of a big welcome page for me. I'm going to go ahead and continue the layouts. We're just going to keep this, it's not really our page, but you can see they've got some content, and it's going to make for a good demo. So once we've got this, we need to go ahead and choose what layout we want. I'm going to go ahead and pick hack, which has this nice green view to it, but I'm going to go ahead and click on this one, and that's going to go ahead and publish it. Now this did a couple of things for us. First off you'll notice this message up here is telling us that it did create the project, so if we want to view it, we'd go to this page. It's not going to be there just yet because it's going to take 10 minutes. If we click on it now, we're going to get a 404 right there, but if we take a look at our source control, we have a new branch, we have this gh-pages branch. If we take a look at this, you'll see that this has nothing to do with our initial branch. GitHub actually went ahead and created this for us, this gh-pages is a special GitHub branch that's created specifically for the pages. This is what's getting created by this github.io URL. So this URL is looking at our repository and using this. The 10 minutes to activate is how long it takes for it to set up a website for us that's going to be pointed at this location. You can read a lot more about the pages here, I'm just going to cover it briefly just to show you how to get it setup. I'd recommend that for your starting project, just so you have something, you go ahead and use the automatic creation tool, but you could just set this up yourself by creating your own branch and putting the files there. And after you set this up once, you can easily go in there again and change all these files and make it however you want. Through the magic of Pluralsight video, you don't have to wait the 10 minutes for that page to come up, because I've just skipped that time, it's now up. You can see here, our web page is up, I can refresh it over and over so you can see that it really is there, we now have access to download our project as a .zip, download as a .tar.gz or view it on GitHub. And this page is sort of a welcome page. We didn't really have our information up here, this is just the default that comes with the pages, but we can go ahead and put our content in here and this gets us started with some pages. Since it's just an HTML site, we can go ahead and do this like any other HTML site and just include more files and link to them, and it'll all work just fine. So that's how you get yourself set up with some GitHub pages. Summary So at this point, you should have a pretty good idea of how to get started using the GitHub website. In this module, we made sure to cover that GitHub is a hosting place for projects using Git. So it's not just the repository, it's not just for source control, it actually houses a lot more than that, and we've seen a lot of ways that we can use that and build upon it to do some pretty good things with our projects, and it makes it pretty easy to use as well. We've also looked at how we can set up our repositories on our accounts and on our organizations, and how we can get access to them in either location. It's also nice to see that the interfaces are pretty similar between the two. We also discussed how accounts and organizations differ, and a little bit about when you should use each one, because an account is great for a user, but an organization is great for a group, especially if you need to manage collaboration between those people. So it's good for companies, organizations, open source projects, and the like. We also covered a little bit about how you can collaborate and manage some of those permissions while you're working with the organization or the account. So if you are just working on a solo project and want to add one other guy, maybe two other people, you can collaborate and add an extra person as a collaborator on a project. But you could also work as an organization or convert your account to an organization and manage some of those permissions with teams, and we saw a little bit about that also. We also spent a little bit of time talking about how to manage information using issues, and that's good way to track your work as you're progressing on things, even if you're a solo developer. We also talked about how to use wikis to store information, discuss, and get a lot out of the GitHub interface. And we also showed how to set up some pages so you can give your project a public face with a little bit more information than what you get, and a little bit more customization than is standard in just the regular GitHub repository page. So I hope you've enjoyed this module, I think you've probably learned a lot, and I look forward to showing you more about the GitHub for Windows graphical user interface native application in the next module. Thanks again. GitHub for Windows Basics Introduction Hello, and welcome back to my Pluralsight course, GitHub for Windows Developers. I am Brendan Enrick, and together we're going to get started working with the GitHub for Windows client application. Let's go ahead and take GitHub for Windows out of the shrink wrap and try it out. In this module, we will spend most of our time in the GitHub for Windows client. Feel free to open up your own copy of GitHub for Windows and follow along as I cover how to set up our repositories in GitHub for Windows. Once GitHub for Windows knows about our repositories, we'll learn a little bit about how they're managed in the application. We obviously can't cover a source control tool without covering how to make changes and commit them, so we'll be looking at how changes are made locally. Since this is a distributed version control, we will wrap up this module by going over some of the remote source control workflow. Now let's open up GitHub Windows and see what we can learn. Configuration Options After opening GitHub for Windows for the first time, you'll be presented with the chance to set up your account. If you don't have one, you can register one by clicking on the SIGN UP link. It will open a browser window and allow you to create your account. From here, you can choose to create an account at the pricing level that's correct for your needs. For this video, all I need is a free account, so I can click on this button here. Now we're at a pretty standard account registration page. However, since I already have an account, I don't need to sign up here, I will go ahead and close this window and get back to GitHub for Windows. Now that we're in the client application, let's go ahead and type in our username and password that we registered in the previous module, or if you just set yours up now, use that one, and now we LOG IN. The first thing that we want to do after logging in to our account is to make sure that we configure GitHub for Windows. To do this, we click on the tools icon at the top of the screen. From here, we want to choose options. Now we have a few things that we want to consider changing. First, you'll notice that our account is listed here. We don't need to change that now, but you should know that your account information is here in the options section, and you're able to change it in the future. Next, we'll want to configure Git, which means changing some sections of your global Git config. This is where you specify your name and email to be shown with your commits. You'll notice that mine are already here. That's because I've configured Git on this computer already. Make sure that you use an email alias that you're okay with having shown next to each commit you make. This information will be shown either publicly or privately, but to anyone who has access to see your publish commits. So just be careful with the information that you provide here. Your default storage directory is another important piece of information to configure. Every repository that you set up locally will go in this location by default. You can choose other locations, but it's good to have a convenient location for this already set up. You'll notice that mine is pointed towards the development directory where I store all of my GitHub repositories. You also have the option to scan for any existing repositories. I already have some repositories in this folder that I created ahead of time. You'll notice here that I have a couple of folders, one of which is a repository. Let's go back and click that button. When I click this button, you can see that GitHub for Windows is giving me the option to include the repositories that I already have in that folder. I am going to exclude two of the projects and go ahead and add the remaining one. Once we're done in the options window, we'll see that the project is now being tracked by GitHub for Windows. So once I get rid of these, this OneRepositoryToFind will now be tracked. You can also change the default shell used by GitHub for Windows. I used PowerShell in the first module, but if you're more comfortable in a different command line interface, you are able to change this. Just click on the one that you want to use. You could use the standard Windows command line, you could use Git Bash if you're used to Bash, you could use PowerShell, or specify any custom shell that you have installed. I'm going to go ahead and leave it at PowerShell. Lastly, you're able to change the default pull behavior in GitHub for Windows. I haven't explained the difference yet, but there are two ways of handling conflicts in Git. You can merge or you can rebase. Both achieve similar results, but do so in a different way. I will explain in which situations I use each type of conflict resolution. I'll explain this in a later module. Once I've done that, you can then make the choice of which one is appropriate. This selection here, however, will choose which one you want to have as the default. You can come back here later and choose your own default once I've explained the differences. Now let's update these options and set up our repository. Notice that OneRepositoryToFind is now listed inside my local repositories section. Setting Up Repositories The next thing we're going to do is create a new local repository. To do that, we want to use the +create button at the top of the screen. For now, we are going to create this repository locally, so leave the Push to github button unchecked. Let's go ahead and make a repository named only-local-repo. I'm going to leave the description blank here. Please notice that the location of my repository is the default one, I just set it up. You can click the ellipses to change from that default. However, I think this location will be fine for us. Now let's create this repository. Now that we've created this local repository, you'll see that it's tracked under our local repositories screen. You'll see it listed here after our OneRepositoryToFind that we added earlier. Now we're going to see how we can connect repositories to GitHub. This repository we've set up will allow us to work locally. We can make changes, and in fact we can commit these changes that are already here. You'll notice that our .gitattributes and .gitignore files were created for us already. In order to commit these, we just need to type in a commit message. And then we go ahead and click this checkbox, which will commit our changes to master. In this case, master is the branch that we're working with. Now our changes are committed. If we want to push these changes to GitHub, we can go ahead and click on this push to github link. Since we haven't connected this to GitHub before, we're prompted with the opportunity to connect to GitHub. Since we're going to be using a public repository, we don't want to check the Keep this code private checkbox. We do, however, need to make sure that our account is selected and is the account that we want this repository associated with. And since that's the correct one, I'm going to go ahead and click this PUSH button. And now my repository is connected to GitHub. Now that we've connected our repository to GitHub, we can go and take a look at all of our changes there. Now keep in mind that we only have one commit we've sent up there so far, but to check it out, all we have to do is click on this with the right mouse button and choose view on github, and that will open up our web browser. Now that we're on the website, you can see that we have our initial commit with a couple of files, happened a few minutes ago, and we're able to work with this in GitHub. The next thing that we want to do with our GitHub account is to create a new repository. In order to do that, we're going to go ahead and click on the Create a new repository button. We've done this before, all we're going to do is create one of these so we can look at how cloning works. So now that we've created this new repository, we're going to go ahead and use a little shortcut that GitHub for Windows gives us. You'll notice this Clone in Desktop button down here, and you'll notice that that icon is the same icon used for local repositories in GitHub for Windows. If we click this button, watch what happens. You'll notice that GitHub for Windows has brought us to the local repository screen for this repository. It has also automatically pulled that repository down, so we're now able to work with this one locally, and that's a great shortcut for getting your repositories set up, and that Clone in Desktop button will work with any repository that you find on GitHub. If you were paying attention earlier, there were two projects that I did not include when I was scanning for existing projects when changing the options in GitHub for Windows. Those two projects are shown right here in this Explorer window. Now the reason that we're looking at this is because we're going to be copying these into our GitHub for Windows, and it's going to start tracking these repositories. You'll notice that each one of these is a Git repository. Let's go ahead and drag one of these in. You'll notice now that that repository is being tracked by GitHub for Windows. The next cool way that we'll be getting our repository into GitHub is by using the browser window itself. Let's create another repository on GitHub.com. (Typing) Now that this repository exists, we're going to need to drag its URL into GitHub for Windows. Let's go ahead and shrink down that window and drag the URL over. You'll notice that it pulled in my repository again, so now GitHub for Windows is tracking this repository as well. Another cool way to create a local repository is to set up a folder in Explorer. Notice here that I didn't include any spaces. That's because it's important that this name match with a valid repository name in GitHub, and we can't have spaces for those. So now even though this is not a GitHub repository, I can take this folder, drag it into GitHub, and upon doing so, it prompts me to create a new repository in this location. I'm going to go ahead and click CREATE. And now if we switch back to that window, you'll see that all the required Git files and folders have been created for us. This repository is also now being tracked. Now I am going to show one more way that we can add in another repository to GitHub for Windows. Let's go ahead and click on the github section and click on my account. When I do this, I see a number of different repositories. These repositories are all ones that I've been creating, and they're just sample repositories. Let's go ahead and bring one of these down. If I click on this repository, it brings up the README file over here to tell me a little bit about it, however, the README file on this was pretty much blank, it only had the title. In order for this to be used locally, I need to clone it. Once I've done that, I now have a local copy. So if I click on this, it will open up the repository and I can see all the commits that are in here. Now if I go back to local and go to repositories, you'll see that it's here as well, along with all of my other local repositories. Local and Remote Repositories From this view, we can take a look at our existing repositories on the GitHub.com website. These are all of the repositories associated with my account. You saw these in the last section of this module when I was showing how I could clone locally. You'll notice when I mouse over each one of these, they show me a great deal of information about them. This information is all useful, and I'll go ahead and explain everything that's on this page. The first thing that I want to make sure to note is that when you click on one of these, it brings up the README file, if there is one. For some of these, we have information on the README file, on other ones, there is no README file. And some of our README files, while they exist, are lacking in information. Notice this icon that has this screen here. Each one of those is a repository that I've cloned locally already. If I click on the arrow, it'll go ahead and open this repository and it'll bring us to the screen where we can see all of the information about that repository. If we go back, we can continue looking at the information on this screen. This icon over here on the left indicates that these are repositories that exist at other locations. You'll notice that the ones that we have locally when we mouse over that repository are showing us two pieces of information. They're first showing where the repository is on our local computer, as well as the location on the website. BrendanPluralsight is my account name at GitHub, and the name following it is the name of the repository. That's the location where it's stored on GitHub. You'll also notice that it shows the local folder of that repository. Additionally, it shows the .git location. On the ones that aren't' cloned locally, they only show the account name and repository name, which is where it would be located on GitHub.com. And that's pretty much what's on that page. You can also filter and find only repositories that match with that name. Once you have quite a few, this becomes more useful. If we take a look at our list of local repositories, there are a few things that we can do from this screen. One of the first ones is just like on the remote repositories, we can go ahead and search. This filter will limit us down to only the repositories that match our search criteria. This is useful if you have a lot of repositories. The next thing that I want to show on this screen is how you get to the Explorer version of this. If you right-click, you have a few options. You can view it on GitHub, which will open up a browser and take you to the website, you can open it in Explorer, you can open a shell here, and you can tell GitHub to forget about it. If you stop tracking this repository, the files will still remain, but it won't be in GitHub anymore, at least your local copy won't. If you have a published version, that will remain there, and this desktop version of GitHub for Windows will not be tracking it any longer, you'll have to clone it again if you want to continue working. Let's go ahead and see what each one of these does. If we open the repository, it takes us to the information where we can see if we have any uncommitted changes, we don't right now. We can also see our commit history, as well as the files associated with any of those commits that we have selected. If we click on view on github, it opens up GitHub and takes us to that repository. If we click open in explorer, it opens up that folder in Explorer. Clicking to open the shell will bring up our shell window where we can go ahead and use the Git command line that we learned about in the first module. And finally, if we click stop tracking this repo, it will be removed from this view. The files will still be on the GitHub.com website, and in fact the files are still on our computer. However, GitHub for Windows, the GUI client, is no longer tracking them, and so they don't show up in this list. Committing and Syncing Now that we've got a handle on how you can manage and work with your repositories, it's time that we start using them and start making some of our modifications, committing changes, and start seeing how our source control is actually working. The first thing I'm going to do is open up one of our repositories. Let's go ahead and open it in Explorer so that we can make some file changes. The first file change that we want to make is that we need to modify one of these text files. Let's start with the README file and makes some changes. In this file, let's go ahead and add some text. (Typing) Now that we've got some changes in here, it's probably a good time that we did a commit. Obviously we're not done yet, but we do want to commit some of these, so let's go ahead and do that now. Let's open up the project, and now that we're in here, we have a few things that are available to us that we've seen a little bit before, but we haven't really talked about. The first thing here on the left is this uncommitted changes section. You'll notice that it has the ability to hide and show, if we had a larger history this might be useful if we were looking through the history and weren't really committing right now, but wanted to see some previous information. Since we're in the process of committing, we want to take a look at our changes on the right, you'll notice the green highlighted sections are the new parts that we've added, and you can see all the changes, they're all preceded by these plus signs for all the added lines. We can decide if we want to include this file or not, which obviously if we don't include it we're not going to be committing anything. We can also collapse this section if we don't want to see the changes, and if we had more files we could do that with them as well, and we'll see that in the future. We can also choose to select or unselect all. And we have two boxes to commit information when we commit our changes. The first one is the primary commit message, and this is what's going to be shown most often when you're looking at this commit. However, if you have additional information that needs to be included, that might not be able to display in some places, you can include an extended description. This is not required, but allows you to include detailed information about what was actually changed. So if there were some important details about the commit that needed to be in here, you could put the information in here and have a brief message that says what was actually, what's most relevant. Let's go ahead and type a message about this so that we can see how we might use this. (Typing) Now that we have a basic message, I'm going to include some additional extended description. (Typing) So now I've got a more detailed message. Obviously that message is probably too long to include in the commit line, so we kept one short that just says what we were doing, and you might include something about whether or not you actually finished it or if you were resolving some bug you might include the ID or some other relevant information there, but you don't have to do that, it all depends on the standards that you're working with. So the next thing we need to do is click on this little checkmark here, and this is going to commit or change to master. So what that's telling us is that we're committing to the master branch, which is the branch we currently have selected, and we'll learn about those a little bit later. So for now, if we go ahead and check this, we will have committed our change. You'll notice that that change is right here, and it's not included in part of the history yet. Now the reason for that is that this is an unsynced commit, so this change is currently only local, so that's why they're keeping it separate, and this is just a way for you to see that you have changes that are not committed yet. If we mouse over this sync icon here, you can see that our branch, our local copy of it, is ahead by 1 commit and behind by 0 commits. That means that we have 1 commit that we have not pushed to GitHub.com yet, and GitHub.com does not have any commits that we don't have. So we've got all of theirs and they don't have all of ours, but we're probably not ready to sync yet, so let's go ahead and make some additional changes. Let's open up Explorer and take a look at our files again. Let's go ahead and change this same file one more time. (Typing) Let's go ahead and make another file now so we can look at a couple of changes. (Typing) So we've added to two different files, one file was a new file, and one file is an existing file. Let's take a look at what our commit change window looks like now. If we click on this show button, it brings up this information. You'll notice these started collapsed, I can go ahead and expand these, and you can see the information that we've got in here. If I maybe have some reason why I only want to commit one at a time, I can uncheck that and say (Typing). So, once I've done that, I can go ahead and commit this, and now you'll notice that I have two unsynced commits. You'll also notice that my README file is still here. I can commit that now or I can go ahead and make more changes and then commit it, but I'm going to go ahead and commit it now. (Typing) So now that those two have been committed, I want to do one last thing, which is to show you a little bit about what happens when you remove some lines, and we'll take a look at how the diff view on the right is showing us what's changed. If we go ahead and take these lines and just rearrange them, (Typing) now we have some significant changes to this file. Let's take a look. So you'll see that it is detected that the lines have been deleted down here at the bottom, and they've been added here at the top. (Typing) This time I'm going to leave the extended description blank and commit. So now if we take a look at the sync, we have four commits that we're ahead by, it's probably a good time to push these out as that README file is now in a much better state, and we've included some additional information. So we're assuming that we're in a condition where other developers on our team are actually going to want and find value from the commit that we've just made. So let's go ahead and sync. Once the sync is complete, you'll notice that all of my changes are now listed in the history. Because of that, we know that they're all up on GitHub.com at the central repository. Reverting and Rolling Back So now that those files have been synced, you'll notice that it's telling us that we are in sync already, and so that means that we don't have any changes that need to be sent up or pulled down. Keep in mind that synchronizing in GitHub for Windows does both the push and the pull operation together. If you were using a command line, you could do one and then the other, but GitHub for Windows is just going to get you back in sync every time. So it's going to do a push and a pull if they're required. One of the next things that we want to look at is how we can undo some of our changes. So this last change that I made was to shift some things around. Well, perhaps I didn't really want to do that, so let's go ahead and take a look at these two options, revert and roll back. The first thing we're going to click on is to revert. If we do this, you'll notice that we now have this unsynced commit that was automatically created for us. It has a commit message that says it reverted and the message is the previous message, so you can see which commit I have reverted. And the way that it does this is it just does the reverse of the operations that were done in the previous one, effectively undoing it, but it does so by doing its own commit. So if I were to sync at this time, it will actually go and add one additional commit that undoes the previous one. And you'll notice that they are both listed here now, and we can see what happens in each one, and you'll notice that they are mirror opposites. Also notice that the description, this is the extended description, the optional portion of our commit message, specifically gives the unique ID of that commit. That ID number is specific to that commit and that commit only, so that's how you can make sure that you know precisely which commit was undone. The next thing that we're going to try to do is a roll back. The way that a roll back works is that it's going to undo our commit rather than committing a new commit that reverses our previous one. So revert is another commit of its own that reverts the changes in the previous one, a roll back is undoing one of those changes. Let's go ahead and make a commit, and then we're going to go ahead and roll it back. (Typing) So now that I've made that change, let's go ahead and take a look at what I did. I added in some new text and I'm going to go ahead and commit it. So once that's committed, perhaps I realized a little while later before I push out, oh no, I didn't mean to do that. So let's go ahead and roll this one back. So when I do that, you'll notice that my change is still here, I haven't actually modified the file, but what happened is that the commit itself is gone, so you'll notice I'm back in sync, I no longer have an uncommitted change. So I can go ahead and modify that file again. (Typing) So now that I've made that change, I can go in and commit it again. (Typing) So now it's ready to actually get pushed out. So this is a way of very easily undoing something that you did by mistake, and it leaves it so that you don't have a revert commit inside of your history. Now there's personal preference over which technique you use to undo something you've done by mistake. I usually prefer having the commit, which maintains the history and keeps everything a little bit truer. Yes there's some side effects to this in that your history becomes a little bit longer, however, I think that it ends up being a much nicer situation. Let's go ahead and sync. Summary Over the course of this module, we looked at quite a few things. A quick summary of those include configuring GitHub for Windows, we went through all the different options and what you can use them for, and how a few of them are important to make sure you customize at the beginning of your work with GitHub for Windows. Some of them just come down to personal preferences. We looked at setting up repositories in a variety of different ways. We also took a look at how you can make changes to your files and commit them, as well as syncing those changes, which is a push and pull operation with the server, sending those files and their changes back up to GitHub.com. And we also took a look at reverting and rolling back our changes so in case we made a mistake, looking at how we can modify those a little bit. In our next module, we'll be looking at some more advanced concepts than what we covered here. Hope to see you back soon. Teamwork With GitHub for Windows Introduction Hello, and welcome to my Pluralsight course, GitHub for Windows Developers. My name is Brendan Enrick, and in this module we'll be discussing teamwork with GitHub for Windows. During this module, we will spend most of our time in the GitHub for Windows client. However, we will also be using the command line shell, as well as the GitHub.com website. As we learn more about teamwork with GitHub for Windows, we'll be looking at a few things. The first one is merging and rebasing. We mentioned those in an earlier module, but now we're finally going to look at them. We'll also be going over branching and merging your branches back in. We'll take a look at stashing changes and how stashing can help you prevent conflicts. We'll also be looking at how you can resolve conflicts when you run into them. And finally, we'll be taking a look at .gitattributes files and how you can use them to improve your check-in and check-out process. What Merging and Rebasing Are Earlier on in this course, we mentioned two concepts, merging and rebasing. When we discussed those two, I mentioned that I'd be explaining them in more detail later. The first time we saw them, they were options to be used as defaults when we were pulling down data and we would need to either merge or rebase, and we could choose which one we wanted GitHub for Windows to use by default. I'll be explaining the differences between these two scenarios, merging and rebasing, by using examples of each one. We'll take a look first at an example of merging, and then we'll go into an example of rebasing. We'll then take a look at when rebasing can actually be a dangerous operation. There are some reasons why many people recommend against using rebasing, but there are also many developers that will tell you that rebasing should be used as often as possible. We'll be looking at an example of when it can be dangerous, and then I'll take you through some scenarios, and I'll at least give you the preferences that I use when determining whether or not to merge or rebase. However, keep in mind that teams should decide which approach makes most sense for their situation, as the amount of information stored in each portion of your history is going to be determined by which approach you take by default in certain scenarios. Let's go take a look at some examples. Now let's take a look at our example of merging. When we start off, we're going to have two commits on our version control history tree. You'll notice that we have A and B commits. This represents that A happened before B, although the lettering is really just used as distinguishing for us. In the back-end you'll remember that Git is actually using a special unique identifier to track each one of these. In our case, we're going to try to represent that a little bit more visually rather than using a long, unique identifier. We're going to have a developer make a new commit of his own. We'll represent this by having the commit on a separate path. You'll notice that we deviated a little bit. This has to do with how Git works. You'll remember that each developer is working on their own local workspace, and they have local repositories and that effectively makes it so there are branches that are different from those in the central location. While our developer is working on their own stuff, other people are committing and pushing into the centralized location. So we'll occasionally get other commits there. And our developer will continue working while everybody else on his team occasionally might commit something and will end up with maybe a few commits that they've put in here, and we won't worry too much about how the other developers got their commits in there, but suffice to say that we eventually need to merge our code back in. So at the completion of this feature that we're working on, it's important to us that we commit this back to everyone else. We've committed three change sets here, F, G, and H, and now we need to send these back. We have two options. We can either merge our changes back in or we can rebase. Since this is the merging example, let's take a look at how a merge would work. When we do a merge, what we'll end up doing is making a new commit that combines our changes with the changes that are already on the main repository. This new commit is going to end up being represented as a merge commit on the main tree. You'll see here that we've represented that with the letter I. So everyone who looks at the history on the main branch there will see our change set that commits all of our branched changes that we've just merged in, and that's an example of a merge. Now that we've seen a simple merge, let's take a look at one example of how rebasing would act differently. We'll start off with the same two commits. We'll have A commit and B commit. A happens before B, and then when our developer goes to make his own change locally, he ends up, we're going to go ahead and just call this one F again, as we're going to have this same example as before when we start off. So while our developer is working on his changes locally, another developer pushes in a change that makes it to the centralized repository. The developers on the team continue checking in and so does our example developer. All these commits continue happening and our developer eventually finishes F, G, and H commits. Now this feature is done. In our last example, we had our developer do a merge to combine his changes back in where there was a merge commit added on as the newest commit on the main branch. In this scenario, we're going to look at a rebase instead and see how that changes things. A rebase, rather than merging in the changes and being represented with a commit that does the combination of these two, instead the rebase is going to rewrite history. Instead of F depending on B as its starting points, we're going to pretend that we didn't start working on F until E, the last commit on that history there, was already committed. When we do this, our rebase is going to end up looking like this. So now when we send this to everyone else, they will not see a merge commit, they will see a straight line, and this is significant because it keeps the history a little bit cleaner because there's no merge commit, and if we were working on separate files, there wasn't really much need for a merge commit in the first place. Let's take a look at another example. Since rebasing is a little bit more complicated than a merge, and is likely something you're less used to, since merging existed in the old centralized version control systems, and rebasing only became common in the distributed version control model, let's take a look at a more complicated example. We'll start off with the same commits that we had before, A and B. We're then going to have our developer make another commit, C. Once our developer is done making changes to C, he's going to go ahead and push it in for everyone else since it's something that everyone needs to depend on, perhaps it's an interface of some kind and everyone needs to work with it. So we're going to push that onto the stack. Now everyone has access to that commit, and because they do they're going to start building new code based on that. And over time, we'll end up with quite a few changes, all depending on C, some of them from the other developers, and some of them from our developer. In this scenario, we now want to get our changes back in line with everyone else's. We'll take a look at what happens when we use a rebase. So what we're going to do at this time is update it so that our code instead of depending on B as its base point, we're going to change our base so that it's now E, and it looks like F and G were depending on that. The reason why we did not take C with us is because we rebased, which means that it checked and saw that the code C already existed in that line and said that we didn't need to add that in, because C already existed and we were depending on it. So we merely updated our code, F and G, to match with that new base. That means that we were able to save ourselves a little bit there since C existed in both places. This has to do with those unique identifiers that exit on each commit that our distributed version control is able to see and help us work with. Dangerous Rebasing Let's get started looking at an example of when a rebase can be dangerous. We're going to keep this example a little bit simple, just for time, so that we don't get into one of those complex scenarios that can really mess up your version control, but this will illustrate some of the dangers and it'll allow us to explain some good practices that can help you avoid making a rebase dangerous. Let's take a look at this simple example. We have A and B, just like we did before. I'm going to make this one a little bit easier to read by adding in some labels. So in this scenario, we're going to have you decide to make a branch and start building your new feature in this branch. While you're doing this, others are going to continue committing onto the tree, they're going to commit to the main branch and push in their changes, and you'll keep working in your feature. In order for you to access your feature from any computer, you push your branch to the central repository. This means that someone else can start their own work using your branch. I've represented this here with another developer who has started working locally with your branch. Once you're done with your feature, it's fully tested and you decide to push it back in for everyone else to use it, you rebase it onto the main branch and push it out for everyone to use. Since you know that it's going to work, you've rebased it in and you now have two new commits. You'll notice that D and E are no longer the same as they were before, they have new IDs because they're based on a new base. That's why I've colored them with a different border and they look a little bit different from the other one. That's just to represent that change. Now that G and H are depending on the old D and E, they're now depending on these obsolete changes. The D and E they depend on are not going to be merged back in since we already rebased in a D and E change already. Let's take a look at where things can go wrong from here. Imagine that you've told the other developer about your rebase, now that other developer can rebase onto the new branch, or I should say the original branch. This mostly avoids the issue, the other developer may not have wanted that F commit you'll notice that started getting built off of this, but as long as they know to avoid it, they can rebase onto E and continue working there. That other developer might not have been working on a feature that may have been a custom build of your software for a client or something along the likes of that, at which point F needs to be avoided. Let's go ahead and take a look at what might have happened differently. So if we back up and take a look at where we were before the other developer rebased, this time let's imagine that the other developer was working locally and we didn't know that they were using the code, and they decide to merge in. When they do this, they're going to end up with a new merge commit, I, just like we saw in our merge examples, and in this case they'll have a duplicate set of D and E that get merged in. Since D and E have the original version based on B and the new version based on C, Git considers these to be two entirely separate commits. Because of this, we end up with potential problems and conflicts. Likely both of those are altering some of the same files. It's possible that they've been moved around or changed, and if that happened, then we could end up with a duplicate of the code. Either way it's a messy situation that we now need to work our way out of. Is it unrecoverable? No, but it is a little bit dangerous because we end up with a whole bunch of duplicate changes and a lot of conflicts, and so it's hard to tell which pieces need to change and which pieces were just duplicates caused by two D and E commits. Either way it's a scenario that we want to avoid. Good Examples of Merging and Rebasing Before I get into some discussion of rules about rebasing and when you should use each one and which ones are good and bad, I should start off by saying that good and bad in this case are very subjective. Teams work differently, they have different preferences, and there are different scenarios where each one makes sense. If your branching and merging structure makes more sense to rebase or merge in some certain place, by all means us it. Please consider the examples and how they apply in your scenario, and your team, your communication, and your branching and merging structure. Each one is different and there are really only a few different ways to do it anyway, so find the one that works best for you. I'd like to start off by pointing out three common rules that I use when rebasing. The first one is once I've pushed out a change, I never rebase. I also never rebase once there are commits that are depending on a branch that I've made, I don't rebase that branch because there are other commits depending on it. These two fit very nicely into that last scenario that we looked at. You also don't want to be doing rebases while depending on code from someone else's branch, because you don't know for certain how they're going to be handling it, and so it becomes a slightly dangerous situation when you're using them. If you follow these rules, you can pretty much rebase safely in most instances. Just think about what's happening and be careful, and rebasing can give you a really, really nice history. So now that I'm done scaring you about using rebasing by talking about dangerous situations and ways that you need to work with it to be careful, I'm going to talk about one way that it's good to use a rebase. Let's start off the way we always do with an example. We'll start off with some commits that have been made by the team, and we're going to have commit A and commit B. We're then going to have another developer, Steve, commit a commit C. This change is going to be a small single file commit that Steve makes. We're then going to have Brendan also make a small single file commit. Let's go ahead and say that they're two different files. When Steve rebases C back in, it ends up depending right off B and ends up being a nice little commit there. Now we're left in a situation where Brendan has to decide if he wants to either merge his change back in or he can rebase in and depend directly on C instead of depending on B. If he merges, he'll end up with an extra commit, E. When he does this, you end up with a commit that does a merge, it's got merge in the name, and it will depend on C, and it will have the changes that were made in D. But was that extra commit really needed? Do we need to C the extra branch out there on our version history? Remember that Brendan was really only changing one file, and it wasn't a feature, it was just a single file change and it just happened that Steve committed and pushed his change before Brendan committed and pushed his. Let's go ahead and back that out. So now we're back to the point before the merge happened. Let's look again with a rebase. When we do a rebase, now we end up with what really happened, or sort of, at least what we'd like to think is what happened. This makes it a little bit cleaner and easier to read because we had commit A, then commit B, then commit C, and commit D. Since C and D didn't depend on each other, they could've really come in in any order, and it could've been merged in, but it really doesn't make much difference in the history since they affected different files. There was not really a need for a merge. And that's an example of when it's good to use a rebase. Now I'm going to walk through two good merge examples. We've taken a look at when we can use rebasing, let's take a look at some merging. Keep in mind that these are some examples that we can use for merging, but we can also rebase in these cases as well. So, we start off with the same scenario we've had each time, which is there are a couple of commits that exist in our history already, we're going to go ahead and branch. When we branch, we're going to start working on a new feature. While we're working on this feature, others are going to continue committing and pushing into the main branch. While we're working on our feature branch, eventually we'll complete it, test it, and want to bring it back in. When we do this, we can either merge or rebase, either one works well, but let's take a look for this example and how to do a merge. Some teams like having features that get merged in nicely. When we merge this in, we end up with F, which is a merge commit whose primary existence is just to declare that there was a merge that happened. Many teams like this because it represents that the feature has been completed and merged in at this point. All future development of that feature is likely going to happen here or is going to be represented with some kind of a patch of some kind. Since the feature is done being developed, it's now part of the main branch, and there's a merge to represent this transition. Some teams like to just have the rebased version, though, where you end up with a straight line showing all those pieces. It really comes down to preference, but this is one example of where a merge would be interesting. Let's take a look at a very similar example. In this example, we end up with the same starting scenario, and we add in our change, but this time let's imagine that no other changes were made in the main branch while we worked on the feature branch. If we attempt to merge back in, what will end up happening is since no change has occurred there, no merge commit will happen by default, and it will actually just send up back in and it will look the same as if we'd rebased. If we want to preserve the fact that we used that feature branch, there's actually a no-fast-forward option in the command line version that will take care of this for us. If we're not doing that, if we're using the GUI, we can't preserve that feature the way that we want to with a merge commit, so we'd have to switch to the command line. But let's take a look at what it would look like. We'll end up with a merge commit as long as we pass in the parameter, telling Git that we don't want to have the merge become a rebase, we want it to just merge straight in so that we can preserve the fact that we had that branch out there. And this is just a preference, if you want to do this differently, then you can go ahead and have it rebase or however you want, as long as you make sure that you're following some careful rules about sharing and paying attention as you rebase things back in, you just want to make sure that you don't change history in ways that it would affect other commits. So just pay attention and be careful. Branching and Merging Demo Now that we understand a little bit about how branching, merging, and rebasing works, let's go ahead and take a look at some of these examples in GitHub, and specifically we're going to look at branching and merging branches as well while we're in there. So you'll notice that I've cleared out my local tracked repositories in GitHub for Windows to make these examples a little bit clearer. Let's start off by setting up a quick repository. I'm going to go ahead and create one, we're going to let it push to GitHub, and we're going to go ahead and call this one branch-merge-demo, and I'm going to go ahead and Create it. The next thing we need to do is we need to make sure that we commit and push this to GitHub. Now that it's commit, we need to publish. After publishing, you'll notice that we still need to sync that change, sending it up to GitHub. Now our change is up there, we can go ahead and start working with this repository. We've got our repository set up, connected to GitHub, and we're all ready to work with it. Let's go ahead and create a file here just so we've got something to work with. (Typing) Now we've got a file in here, let's go ahead and commit. Now that we've got this change and everything is synced, let's take a look at how we can make a branch. You'll notice that we've been working on the master branch this whole time. You've seen this in every example that we've been working with so far, let's go ahead and change the branch. To do that, we just click on this, which brings up our branch-switching menu. From here, we can filter or create a new branch by just typing one in. I'm going to show you the more advanced few, and then we'll jump back to this one to use it. The more advanced view shows you a large view of all the branches and gives you some additional options. The merging is down here at the bottom, and we'll have a list of branches here once we've created some. Let's go ahead and create a branch. When I filtered for this, since it didn't find any branches that match the name I typed in, it gives me the option to create a new branch from the master. So I'm going to go ahead and click on this button. Now you'll notice that it has changed the title up here so that I'm no longer on master, I'm now on feature xyz branch. That's very useful to just make sure you glance at that from time to time so you know where you're working at any given time. Let's go ahead and make a change on this branch. So now that we've made that change, there's a couple of things that need to happen. The first one is that we need to publish that. Publishing is essentially telling the centralized repository that this exists. We get the option to publish it or not, if we publish it we make it accessible to everybody else. If we don't publish it, we're just working locally. We also currently have some changes. Let's go ahead and commit these changes. Now that they're committed, they're ready for me to continue using, and I can actually work with them locally. I can actually merge right now. Let's go ahead and merge these back into the master. So in order to do this, I drag the branch I want to go from and the branch I want to go to, and you'll notice it describes it now as feature-xyz to master going into master. And so this illustrates very nicely that the change will happen on master on this case for me. Now normally I would go ahead and pull and then do this just to make sure that there weren't any changes in master, but I happen to know that there aren't any because I'm recording a demo. Let's go ahead and click Merge. So now my changes should have made it back into the master branch. Let's go ahead and switch back. So now I've switched back to the master branch, and you can see that I have an unsynced commit from my local feature branch. Because I never pushed it, it's actually a local commit still. You can see up here that I can actually sync this branch up. So when I do that, it's going to send that change up to GitHub and allow it to be used by anyone else. My branch still exists. I can go back to it, it still hasn't been published, you'll notice that it has everything down here under History, with no uncommitted changes, no listed unsynced changes since I merged them back to another branch already. If I continue changing here, you can see that I've got this change again, and I can continue using that same process. Now let's say that I want to work with someone else. In this case, I need to click on publish. When I click on publish, this sends it up to GitHub, so now GitHub knows that this branch exists whereas before it was just kept locally. The danger here you'll remember is now other people can work with this code. Luckily for now, I'm just doing merges instead of rebasing. Let's go ahead and sync this. Now that everything has been synced and working, we can go ahead and start using our new branch, and everybody else can work with it as well. At this point, behind the scenes, I've gone and made a change to my GitHub repository. Let's go ahead and make a change to the master branch. Let's go ahead and make a change to the readme file. When we're done making that change we need to make sure that we commit. Now we have an unsynced commit. If I mouse over, you'll see that I am ahead by 1 commit and behind by 0 commits. Let's go ahead and click this. If I switch over here you'll see that I'm behind by a commit. Now we have some changes in each of the branches. Let's go ahead and merge them together. Since I'm going to continue working in the master, I want to merge the change that was made into the feature branch back into the master branch. So let's go ahead and drag where we want to bring the feature the code from where we want to send it to, and you'll see which one is going to change, which is master. And when we do that, the update has been made in here. You'll notice that it created this merge. Let's take a look at what that looks like in History. See here that we have this Merge remote-tracking branch origin/feature-xyz, this shows that we merged in our branch, which is called origin/feature-xyz, because it is the feature, it's out at origin right now, which is the GitHub location, it's just the nickname for it, and we have this unsynced merge. Let's go ahead and sync this now. As soon as that's sent up there, you'll notice everything shows up. These are those pesky merge commits that we were talking about that always happen. Let's take a look at what would happen if we did a rebase on something like this. So I'm going to go ahead and make another change behind the scenes on master, and I'm also going to make a change locally on master, and we're going to go ahead and watch what happens when they rebase together. Now that I'm done making my change, you can see that it's updated to tell me that that change is up there and is ready to be synced, but I'm going to go ahead and pretend that I was doing my coding at the same time so I don't know that that is there yet. Let's go ahead and make our change now. Now we need to commit this, and as soon as that's committed to master, you'll see that we have 1 change going up and 1 change going down. Let's verify our settings. If we go here into Options you'll see that we have use rebase for pull. That means that when I pull in the changes, it should do a rebase, and now it has done our rebase. If you look over here on the left, we have from before when we did our merge of the branches, we have this merge commit, but then the change that I made up on GitHub.com is here, and the commit that we just made locally is here, and there is no merge commit. Let's go ahead and do the same thing again, but this time I'm going to uncheck the box. So I've already made my change in GitHub, let's go ahead and make the adjustment here. (Typing) So now I've made that change here as well. Let's go ahead and commit this. Now you'll notice that everything is updated and we've got 1 change coming down and 1 change going up. Let's make sure that we switch this setting. So now we're going to use a merge instead of a rebase. Now you can see that we've got that change that I made up on the server, the change that I made locally, and then there's this merge. So you'll notice that what ends up getting a little bit weird, and this is one of the reasons why a lot of people like rebases, is that this same change is actually listed twice in the history of this, because that merge had to happen. So the fact that that exists two times, sure looking like the same change, the only difference being that one of them is declared as a merge, this is one of the reasons why many people like using a rebase instead of a merge. Before we move on, I want to take one last look at branching and just make sure that I show some of the examples of what you can do inside the more advanced branching screen. In here, we have a few options. First off, you can add a new branch based on this branch, or you can add a new branch based on any other branch that's in here as well. You can also press pushpins to make branches stick around for easy access. You can also delete a branch. Keep in mind that this will get the local and the server copy. However, it cannot also get any other local copies anyone else has. Remember, everyone has their own repository, so if anybody else has a copy of this, they have the branch and you can't delete it from theirs that easily. So, make sure that there's at least some communication. You can also un-publish a branch, which will remove it only from the server and keep it locally. Keep in mind here also that the same thing applies. Anyone that already has a local copy will keep their local copy, there's no way to prevent that. You'll remember that I said you can create a branch from an existing branch. So if I click this button, I can create a new branch. When I do this, it makes a new branch that's based off that other branch. So, when this one merges in, I will often merge it right into the branch that it's from. So you can get some pretty complicated branching and merging strategies going on here, whatever it is that your project requires and your team likes to do. Once you've got this, you can also filter. So once you get too many, you can use this to find the ones you're looking for. Stashing Changes So let's take a look at the concept of stashing. You may have heard of it already, you may not, I would describe it as similar to shelving, which is something that you may have come across in another source control system, but in simple terms, stashing is a way for you to temporarily store some uncommitted changes so that you can do operations while they're stashed. Let's take a look at some cases where stashing can help you. In order to demonstrate stashing, I've created a local repository. Let's go ahead and take a look at it. There's nothing here, all we need to do is go ahead and open up Explorer, we're going to go ahead and create a new file, I'm going to go ahead and call it LocalChangeFile, we're going to go ahead and make sure we make some changes here. Now that we've got those, let's go ahead and commit them. Now I'm going to jump on the server and make some other changes, and we're going to see how another developer's work, in this case I'm going to use the same account, but we'll pretend it's another developer, and we're going to see how we can avoid some changes that they send down to us. So on the server, I went ahead and I created a README file. Let's make sure that we don't run into any problems when we have our own local changes. So I'm going to go ahead and make another change locally. So now I've got some uncommitted changes. That presents a little bit of a problem. The problem that it creates is that I cannot pull down the changes from the server while I've got local commits. So let's imagine that I've got these changes, they're not complete, but I want to make sure that I pull down someone else's changes first. So what I need to do is I don't want to commit them, because if I commit them then I've committed some code that's not really ready to go. I want to go ahead and stash these somewhere so that I can just save them and come back to them. If you'll notice, in GitHub for Windows, I can discard changes or open containing folder, but I don't really have a way to stash these anywhere. So what I need to do, and GitHub for Windows makes this really easy, is I need to jump to the command line. Let's go ahead and jump to the command line now. So now that I'm in the command line, I can go ahead and stash my changes. So now I've stashed my changes. You'll notice that on the command line, it changed a little bit, it had the +0, ~1, and then -0, which meant I'd changed one file, now that's all gone because it went ahead and it stashed these local changes I had for me. So now let's go back to GitHub for Windows for a second, and you'll see that I longer have any committed changes and I'm now able to click sync. It doesn't actually let you sync while you have uncommitted changes, so now I need to go get those changes back. We're just going to go ahead and look at the simple example, so I'm going to go ahead and bring the command line back up so we can get our changes back. So when we do this, we end up with our stash has been saved in a local spot and we're able to get it back. Now the operation that we need to do to get it back is called a pop, and so what we're going to do is we're going to go ahead and pop our change back off, and it's going to take the most recently stashed thing and reapply it over the working directory that we're using. So I'm going to go ahead and git stash pop here. So now that it does that, it goes ahead and takes those files and I now have my changes back. So let's go ahead and close the command line, and you'll see that my uncommitted changes are here again. So I was able to do that even though normally you can't pull while you have uncommitted changes, which is just for some concerns that Git actually has when it's running. So I'm going to go ahead and commit these now, and then I can sync that back up. And that's how we can use stashing so that when he have local changes, we can still bring in someone else's code. And that's one nice way to avoid difficulties there. Resolving Conflicts The next thing that we're going to look at is how to resolve conflicts. Once again, we're going to have to go into the command line in order to resolve these conflicts. Conflicts are a little bit complicated, and you should try to be careful and make sure you've got good communication among your team, just so that you avoid conflicts. Conflicts generally only come up when people are editing the same files. There are some ways you can avoid this, some things that you can do to make it a little bit easier, but inevitably you're going to end up with a conflict, and I'm going to show you a simple way to resolve it. So in order to demonstrate how we can resolve a conflict, I'm going to first need to get us into a conflicting scenario. Let's go ahead and make a change locally, and then I'm going to go ahead and make another change to the same file on the server. Let's go ahead and do this now. Let's go ahead and open up Explorer. I'm just going to modify the README file. Now I've made a local change. Let's go ahead and commit this. Now I'm going to go ahead and quickly make the same change on the server. (Typing) So now I've made that change in both places. If we wait, this sync is going to update and it's going to tell us that we've got a change that we're ahead by and one that we're behind by. Okay, so now we've got that change and we're ahead and behind. We're going to go ahead and get ourselves a pretty scary warning message here. Okay, so obviously something just happened, something went wrong, it says it failed to sync this branch, and that is because we made two changes to the same file. Now Git is pretty smart. It knows when you change a file, it makes unique IDs for everything and tracks all the changes. However, in this case it can't figure out what we need to do since we changed the same stuff, and we don't have any special rules that are in place either. So we're going to have to go ahead and open up the shell to fix this problem. So now we've got the shell open. You'll notice that this window looks a little bit weird, there's some stuff going on, we've got a conflict, we've got green text, we've got red text, clearly something has gone wrong here. Let's go ahead and check the status. When we look at the status, you can see that my branch and origin/master have diverged. Origin/master, you'll remember, origin is talking about the centralized repository or really to place your by default pulling from, and that's going to be GitHub and the master branch there, and my local master branch are not the same. So we need to bring them back together. In order to do this, we need to go ahead and stage these. So we can either do a git add or a git stage, which you'll remember from the beginning are the same operation and one's just alias to the other. So let's go ahead and do that now. So now I've staged the README file. The next thing I need to do is I need to commit my resolution to the conflict. Let's go ahead and open up that file just so we can see what's in there. When I open up this file, you'll see that it has this section HEAD and this section down here. When I look at this, what I'm seeing is the change that I made and the change that was made up on the server. Now I just need to decide how to resolve these two pieces and make the code work again. Since this is just text, it's pretty easy. We can also see that these are both the same change. And I'm just going to go ahead and decide which one I want to keep. So in this case, this text looks a little bit clearer, so I'm going to go ahead and leave this one in place and get rid of the rest, and then I'm going to go ahead and save. Now that I've got that change, I need to go ahead and do something with it. So I'm going to jump back into GitHub for Windows and commit my change. I'm going to go ahead and commit that. Now I'm going to go back to the command line. I'm doing a git pull here just to make sure that there aren't any changes that I'm missing, so nothing has happened while I was resolving, and then I should be able to merge and send everything out. I'm going to go ahead and switch back to GitHub to make sure that this happens there so you can see with that. Obviously I could do the push command here that we showed earlier on in the course as well. And now we've resolved our conflict. So all we needed to do was go back, add the file or stage the file, make the change to actually resolve it, and then we're good. Our merge looks a little bit weird, so you'll see that what we had was these two changes both happened here when we look at our history, and then we have one change here that resolves them together and basically makes the change that I wanted to happen. So it deletes the one and reads the other. That's all there is to it. I have set up here an example that's very similar to our last one. This time we're going to do our merge a little bit differently, but we're going to run into a conflict in pretty much the same way. Let's go ahead and make a local change and a server change, and watch what happens. (Typing) Now I'm going to go ahead on the server and make the change there also. (Typing) So now we've made that change in two places. Let's go ahead and do our sync again and watch it fail. Okay, so we got to the same error that we had before, we definitely failed to sync the branch, let's go ahead and resolve it a little bit differently. This time when I open up the shell, I'm going to go ahead and check status again. So we can see that we're in the same situation as before. We've got our local branch and the master/origin branch have diverged and we need to make sure that we bring everything back together correctly. This time, what we're going to do instead is use the git mergetool operation instead. I'm going to go ahead and pass a parameter to this that will give us the information about it first. So this provides us with a decent amount of information. Since we're on the command line, obviously you're watching a course on GitHub for Windows, not Git the Command Line, so you'd like to solve things with some kind of a GUI rather than here on the command line. So the merge tool is going to let us do that. It's going to let us do our merge from a UI. What we need to do instead is make sure that we choose the correct one. There are, you'll notice, some options that are here by default, as well as some options, which are not available. This list is actually all a bunch of different diffing tools. In this case, I'm going to go ahead and run tortoisemerge in order to do this demo, just because I think a lot of people that watch this course are going to be used to that, but if any of these others are tools that you know how to use, go ahead and install them and you can use them as well. So what I'm going to do is pass in a parameter telling it which tool I want to use, because by default, you're probably not configured to the tool that you want. Now in this case, I'm not going to pass in the file that I want to use, because there is only one file and it's just going to go ahead and load that one by default. So you'll notice that it brings up TortoiseMerge here. And then you can see that I've got my two changes, and I can now decide how to resolve them. I think I'm going to go ahead and resolve it by using my change. So this is Mine, this is Theirs, I'm going to go ahead and say to include mine. So I'm choosing that line to be the one that I keep. So now I've made the change. Let's go ahead and close out of this. Now you can see that I've fixed that, and you'll notice that the green and the red are now gone, so it doesn't have this plus, the tilde, the minus, the exclamation point, none of that's there anymore. So now I can go ahead and fix this. Actually, before I do that there's one more thing that I need to change, which is that I need to commit. Almost forgot. So I did make a change, but I need to commit it. So now that that's been committed, now I can go ahead and sync. And there you go. That's how you can use the merge tool instead of having to just open up the file and deal with those two sections, the head and the other piece, so that way you can use a GUI the whole way and you just need the command line to open up the tool to make the resolution. So if that makes more sense for you, then use that approach. Configuring .gitattributes Files Some of the conflicts, issues, and other consistency problems that you can run into when you're working in a team, can all be avoided by using the .gitattributes file. When you use one of these files in your repository, you'll be able to get a little bit more control over how everyone else commits, as well as how things get merged when you pull in their changes. This can give you a lot of advantage, and it's a very powerful tool. Let's take a look at what it can do for us. For this demo we'll be looking at a .gitattributes-demo repository. This demo is one that I created at GitHub.com, and I've gone ahead and cloned it locally already. Inside of this repository, we have two files, a .gitignore and a README file. What we're going to add now is a .gitattributes file. In order to do this, we can actually get one automatically created for us, or we could create it ourselves. In this case, we're going to go with the easy approach of having GitHub for Windows just create it for us. To do this, we go ahead and go to the Repository settings. Once we're in here, you'll see some of the settings that are available to us, one of them is the primary remote. That is the location where we push and pull to and from. The ignored files in the .gitignore file are also listed in here. And there's this third section, the attributes section, which is where our .gitattributes file will be displayed once we have it. In order to get one automatically generated for us, we just click on the Add the recommended .gitattributes file. Now we have this file. Once we click Update, it'll go ahead and save it, but for now I want to mention a couple of the things that are in here. You can see that there are a few lines created automatically for Visual Studio, so all of my projects there are essentially XML files, and it's saying go ahead and use a union when I merge these. What that means is if two people both add files, when it merges them together, it takes the combination of both changes rather than having a conflict. That's a huge benefit since Visual Studio automatically creates new files at the same place. So if two people make two files, there would be a collision every time. This avoids that. There's also text=auto, which is going to auto detect text files, and it does a few things with that, you'll notice some benefits from it. We also then have msysgit files that it sets up, which tells it how to treat some files that might end up inside of a number of different repositories. I'm going to go ahead and click Update now and we're going to go ahead and see what happens when we use our files. I'm actually going to go ahead and create one additional rule. (Typing) This new foo rule that I've created means that any .foo files are going to be handled with a union instead of doing a merge conflict if I add the same line. Let's go ahead and create a .foo file. (Typing) Inside this file, I'm just going to go ahead and put some numbers to make our demo look a little bit easier to read. These are going to be used so that we can verify that we're changing the same file in both places, and that it's in the same location. Let's go ahead and commit this file. I'm going to go ahead and commit that and push that up to the server, and then as soon as it's done pushing that out to the server, we're going to go ahead to GitHub.com and we're going to make a change to the file that we'll then be able to pull in in a little bit. Notice I'm putting this on the new line 6 just after line 5. That's so that we can verify now in my file I'm going to change the exact same place, I'm going to change just after line 5. (Typing) So notice definitely the same place. Now I'm going to commit this change. Now it hasn't updated to tell me there's something to pull down yet, but when I click the sync button, it is going to pull it down and push my change up at the same time, and it should use my .gitattributes file to make sure that it unions instead of merges, and we'll take a look at the history once this is done. So notice here that there are two changes, one of the, which is adding a change after line 5, and the other one is this is also after line 5. So notice that it pulled in, rebased, and added my change after the other one. So it ends up so that it unioned these two together instead of just throwing a merge conflict, we would then have to use one of those previously learned techniques to work our way out of. This is common inside of make files and other project files and things like that where a lot of times you're just adding a new step, or I should say adding a new file, and when you do that it often doesn't matter the order of those files. So a lot of times it's XML or things like that. So if it's a type of file where the ordering doesn't necessary matter, it's good to do one of these unions to save yourself a little bit of hassle. Summary Now that we're done with that, let's take a look back at some of the things that we just covered. We just looked at merging and rebasing, what they are, what we can do with them, and some situations where merging is good and rebasing is good, and how rebasing can help keep our history clean, yet merging can also keep things a little bit more truthful because we're not modifying our history. We also looked at stashing changes and how we can use stashing to pull in new changes from other people without having to stop our current work. We looked at resolving conflicts and what to do when we run into one, and just some of the basics of how to get out of a hairy situation. And last, we took a look at the .gitattributes files and how they can help us to avoid some conflicts sometimes by making sure that certain files are handled the way that we want to so that the team can all work together nicely without having to compete for who checks in first and who has to do the merge conflict resolution. Anyway, thanks for watching, and I will see you in the next module, which is about all of the social aspects of GitHub. Social Coding With GitHub Introduction Hello, and welcome back to my Pluralsight course, GitHub for Windows Developers. My name is Brendan Enrick, and in this module we'll be discussing the social aspects of GitHub and how you can work with and interact with other developers and development efforts taking place on GitHub. Let's get started. As we start looking at the social aspects of GitHub, we will begin by looking at forking repositories, which will be followed by a demonstration of how pull requests work. We'll then see how we can contribute to a project by reporting issues and how those issues are managed. GitHub also shows us some interesting graphs, as well as a screen it calls the pulse of a repository. We'll take a look at gists and wrap things up by seeing the Profile and Contributions information page about GitHub users. Forking Repositories This may come as a surprise to many of you, but I don't have access to modify every repository that I can find on GitHib. You probably don't have that access either. The way that we can allow ourselves to change the code of a repository we can see, but not modify, is to fork that repository. In doing so, GitHub will create for us a new repository associated with an account or organization we do control. It will keep the connection between the two as well. We'll discuss why that's useful later in the module. For now, let's go find a repository to fork, and see what happens. What we're looking at here is the jQuery repository on GitHub. I'd like to point out a few things before we fork this repository. First, take a look at the URL. You'll notice that the URL jquery/jquery. You'll also notice over here that there is this book icon indicating the repository, as well as the name of the organization and the repository itself right next to it, jquery and jquery again. The first question we need to ask is why we want to fork this. Let's assume that we're using jQuery and we have a scenario that we need to modify. And so what we're going to do is we are going to make our own fork of this repository and be able to make our change and then send it back into this, or continue using our own custom version of jQuery. Either scenario is possible. So first things first. You'll notice in the upper right hand corner here that there is a Fork button. It has a number of forks of this repository that already exist next to it, and I'm going to go ahead and click on that now so we can get ourselves a fork. It goes ahead and plays this animation while it does the forking process, which will go by very quickly, and it's done already. What you'll notice here are a couple of things. The number of forks of the repository has incremented by 1 if you notice that in the upper right hand corner. Additionally, you'll notice that we are on a different URL now. This one is associated with the user account I'm using rather than being on the jQuery organization. The name is reflected here as well on the left hand side next to the project name. There's also a different icon. You'll notice this one has this Y shape, that's to indicate that this is a fork of another repository. Additionally, you can see the information below this that says forked from jquery/jquery, which is a nice convenient link to get us back to the original location. From here, we can go ahead and make a change. We're going to go ahead and change the README file. (Typing) After I've made this change I can go ahead and commit it. Now that this change has been made, we can go ahead and do a comparison and you'll see that while my version has changed, the original version has not. I'm going to go ahead and just modify this address bar so that we can switch to the original location. See how this one still has the original content, and mine does not. And that's how you make changes after forking a repository. Pull Requests So now that we know what forking a repository is, let's go ahead and discuss the concept of a pull request. I recently mentioned that GitHub maintains the connection between the two repositories, the original, and my forked version. Let's say that I had noticed a bug in the repository. After forking the repository, I can make my bug fix and commit the change. Once that's done, I want to help out everyone else by sending my bug fix back to the original repository. To do this, I can simply submit a pull request. Doing so will allow my changes to be merged into the repository that I don't have access to. I am quite literally requesting that my changes be pulled into that repository. Let's go give this a try. While the jQuery repository makes a great example to be able to show a lot of contributions, it doesn't make for a great example for me to be able to demonstrate a pull request. For that reason, I've opened up this repository that I have access to as a modifier, in fact, I am the owner of this repository. In order to do this demonstration, I am currently logged in in an account that does not have access to this repository. In order to show you, I'm going to go ahead and click on the Fork button here in the top right corner. You'll notice that there are no forks of this repository right now, so I'm going to go ahead and make the first one. Once we've done that, I'll be able to go ahead and make a change, and then we'll take a look at the pull request option. Let me go ahead and click the Fork button now. Now that we've got our forked version of this repository, we want to make some kind of a change. I'm going to go ahead and modify the README file. (Typing) Now that I've made my change I can go ahead and commit this. Notice that I am on my version of this repository, this is a fork. Now that I've made this modification, you can see that the change is here, but if I take a look at the original, the change is not there yet. So in order to make this work, I need to do a pull request. Let's go ahead and go back to my version, and then we'll instantiate that pull request. So now that we're back here, I can go ahead and click on the Pull Requests button, which is this icon right here. From this page, I want to issue a new pull request. You'll notice that it brings up a lot of information here. This looks a little bit confusing, but it's actually much easier than it seems. You'll notice here at the top it's indicating the two locations that we're going to be comparing. It has the master branch of the main version of the repository, and then it's also got my fork here, we're also on the master branch of this fork. You'll notice there's a button to create the pull request. It shows that we have 1 commit, we've changed 1 file, there aren't any comments on this, there's 1 contributor, that's just me, and you'll notice at the bottom it shows the changes. If we had more changes than just this one file, it would show them as well. Let's go ahead and click on the Create Pull Request button, which is going to give us some more options. When we get to this page, you'll notice that it's giving us this textbox. What it wants us to do is name this merge request, offering some kind of detailed information about what we did. If we had done more than one change, like more than one commit, it would be a good idea to explain what this sequence of commits is. Is this bug fixes about something, is this adding additional information? In some way we want to describe it so that the person who reads this pull request knows what it is that we did. So in this case, I'm going to go ahead and leave it the way it is because it was one commit, and then I'm going to go ahead and click on the Send pull request button. Once this has happened, I now have a pull request that has been made to the repository. This is the original repository, if you notice in the upper left hand corner, because now the request is on the original location. That means that it's time for me to switch accounts and come right back to you in my other one so we can see how this works. Now that I've switched accounts, you'll notice that this page is slightly different from before. You'll see that there's a Fork, you'll notice that we have this number 1 here listed next to the Pull Requests. Let's go ahead and click on that. So now when we go to the Pull Requests page, you can see that my other user account a minute ago created a pull request. It's now our time to go ahead and use this pull request to merge it into our repository. Let's go ahead and open it. You'll notice here that there is not much complexity, the big thing that's important to notice is the message, This pull request can be automatically merged. That's important because it means that we don't have any conflicts. That means that this merge is going to be very easy. We also have access to quite a bit of information here. We have the title, which says what it is. We can see which branch this came from, which fork, we can see the individual commits. So you can see it's right there. We can check out the file changes. These are the changes. If we wanted to, we could continue a conversation by commenting here. If we comment, that will send a message back to the user that submitted this pull request, and we might do this if we wanted to ask them for additional information or if they needed to update their pull request in some way with additional changes, or something along those lines. It's just a convenient way to talk with the person before you actually merge it in. Since I'm just demonstrating this, I'm going to go ahead and click on the Merge pull request button. It wants me to confirm, and now the pull request has been merged in. So now you'll notice that it is automatically merged, it is closed, this pull request, and if we take a look at this page now, you'll see that my change is now in the README file and if you check the URL, I am definitely on the original version. So that is how you do a pull request, in a simple scenario. We're going to take a look at another way of doing this in a moment. For this next demo, we're going to be doing a pull request, but we're going to do it slightly differently. I have set up a couple of things behind the scenes. You'll notice that I've already deleted my fork that I made in the last demonstration. You can tell because there's 0 Forks in the upper right hand corner. The next thing I'm going to do though is go ahead and make a change to this README file, and I'm actually going to have it automatically create the fork and the pull request. So, if you only really want to change one file, there's a quick way to get it to make the change. Let's go ahead and click on the README file. Now once I'm here, you'll notice it is showing me this Edit button. Obviously I don't have access, but I can click it anyway. You'll notice at the top that it says that I'm editing a file that I don't have access to, and it says that it's going to fork the project for me if I don't have one already. So when I go ahead and make my change, it is actually going to go ahead, fork, and submit a pull request and send this in. Let's go ahead and add something at the bottom. Notice here down at the bottom, instead of saying Commit, it says Propose file change. That's because it's going to do a pull request. When I click that, you'll notice the screen that it takes me to is actually the Pull Requests screen that we saw in the last demo. So as soon as I do that, I can go ahead and send this pull request. You'll notice that it already set up my own fork, and additionally it actually created a branch for this patch. So now that I've done that, it's actually gone and it has added my pull request to that. Let's go ahead and switch use accounts really quickly so I can show you that it's there. Now that we've switched over to this new user account, let's go ahead and take a look at the Pull Requests. And there it is, that's the pull request we just did. It's right here, and I can go ahead and merge that in. And we're done. Nice and easy. Reporting and Managing Issues When you're working on a software project, you likely have a system or process for recording issues found in the project. If you're working on an open source project on GitHub, it's more likely that you'll be using the issue tracker in GitHub. The nice thing about this tool is that people who can see your repository are able to report issues, even though they don't have access to resolve the issues themselves. It's also possible for other people to send you pull requests that resolve an open issue. Let's go take a look at this on GitHub. Looking at this GitHub project, you can see that we've got a new project that I just created, it's got the name This Project has Issues. We're going to go ahead and file an issue on this one, because when I look down at the README file here, you can see down in the description, the README has a mistake in it. Notice it says I'm knot idding, and the k is out of place. So we're going to file an issue and let the person know that this is a problem. Now in order to file an issue, I can be either a user with access to the repository, or in this case since it's public, really any user could do this, but for simplicity sake, I'm going to go ahead and just create one with the user account that has access. So when we get on this new issue screen, all we need to do here is go ahead and give the issue some kind of a title and maybe give it a little description so that the user can track it down pretty well. (Typing) So now that's a pretty good description of what we're really looking for here. There are a number of features that we're not using here, but we can also just go ahead and add a label. I'm going to mark this as a bug, and then I'm going submit. So now this issue exists, and it's an open issue, it's labeled as a bug. If I were trying to track this down, maybe I'm having trouble finding the issue, (Typing) by commenting I can go ahead and have a little discussion with the person who submitted the issue and helped me to track it down. So I'm going to go ahead and comment on that. I might go back to the project, go ahead and Edit, make the change. (Typing) So now I've fixed that, now I can go back to the issues. I can open up this issue, I can say hey yeah, I've definitely fixed this one. (Typing) And then when I go ahead and do this I'm going to go ahead and click Close & Comment, which will automatically close the issue and leave the comment. I could have just closed to begin with, but I like the idea of having a message there saying what I fixed. And that's how you close an issue. If I needed to reopen it, I could reopen the issue and close it again. And you'll notice it keeps track of the history of all of these changes. Repository Graphs and Data The network graph is a confusing name for what it is. It's less complicated than it sounds. This is really just talking about the tree view of the all the changes made to the repository. It's grouped so that you can see the work coming from branches on the repository, as well as all of the branches of the forks of the repository. Let's go take a look at some of these. To look at the network graph, we've switched back to the jQuery repository. The reason is that we want to see a good amount of data. Let's go ahead and take a look at the Network tab. We're going to open it right here. From this screen, you'll notice that we have a fairly significant graph. I'm going to scroll down here. This is the network graph. In this view, you'll notice that along the side is the word jquery. That's referring to this fork, in this case it's the main repository. Below it you'll see another name. If we click and pan down a little bit, those are each forks of this repository. These lines represent a merge from another fork into the main repository of jQuery up here. That's what these vertical lines represent. The horizontal lines are the history along the normal source control. In keeping with a normal standard, the dots represent commits and the lines are the path between them. So if we scroll to the left we'll see a couple more commits, and we can see some commits here that were made directly on the branch. If we mouse over one of these, you'll see the information that was made in the change. If we look at this change here, you'll notice that there is this yellow line coming down. If we scroll down, we should be able to see, after a little while, here it is, that this fork has quite a few changes here. So this fork came off of that version. At some point it might come back in, but for now, that's where we've pulled off. If we bring it back in, it will be added on to this line. For now let's go ahead and take a look at this just so we can see. You'll notice that this developer has been making modifications. If we click on one of these, it'll actually bring up automatically the commit that was made here so we can go and take a look at all the details. If we go back and look at that again, we could also click here, which is the fork itself. And now we're on the network graph from the perspective of this fork. So if we go up a level, this is the fork that we were just looking at in the network graph. And that's pretty much what the network graph is useful for, seeing what's changing, what's going on, and it's especially useful if you're really involved in a large open source project to be able to see where people are making changes. GitHub includes a section of graphs with a bunch of useful information. Using these, we're able to see who is contributing to the project, when it's being contributed to as a timeline, as well as the times of day during the week that it's being contributed to. It's also great for seeing lines of code added and removed, which can be extremely useful when you're trying to track down new features or re-factorings in the repository. There's just a wealth of information in these graphs, and I think it's important that we go take a look at these. So let's go open up GitHub again. Here we are back on the jQuery project. We're taking a look at what we can find out in the graphs. I'm going to go ahead and open up the graphs using this link here on the right, and you'll notice that there are four different graphs here that are available to us. We're obviously not seeing much information just yet. You'll notice that it's suggesting to us that we could look at the Contributors and we can see the contributions over time. We can look at the Commit activity and see over the previous year how much activity is happening at any given time. We can look at the Code frequency and we can see the additions and deletions that have been made. We can also take a look at the Punch card, which is just there to show you when our people are actually making their commits, is it during the day, is it on weekends, is it on weekdays, and it shows you individual days and times, sort of like what the picture shows. Let's go ahead and start with Contributors. So when we open this up, you'll notice that it starts us off with a pretty decent graph. It shows you some of the top contributors and shows you bits of information about them. So you can see when they're committing. You'll notice that some people commit for a while and then don't show up again, others have more consistent commits, but you'll notice that it's pretty common for a hand off or something like that to happen in here when you look at these graphs. Let's go take a look at the next graph. Commit activity is going to show us when most of our commits are happening. So you'll notice over the past year we had a pretty significant amount of commits here on the week of September 7th. Let's take a look at the next one, Code frequency. So I mentioned to you that you could use this to track down when new features are added or when a refactoring may have happened. If we take a look, you'll see that these are probably new features, this is probably some kind of a refactoring, something got removed here, something definitely got added here, but there's definitely a lot of additions and deletions at different points. So using this, I could potentially look at those dates and track down a feature or refactoring that I'm looking for. That gives you a pretty good sense of what's going on in the project. The punch card, in this case, is a little bit overwhelming. Now one of the reasons for this is if you were a small project and maybe you only worked on weekends, for example, you would see Sunday and Saturday would be loaded with very large circles, and then the weekdays would be small. In this case, because it's a large, open source project, there are commits happening pretty much all the time. So you'll notice on the left is days of the week, and then the horizontal is just the time of day, so it's each hour is listed there, and so you could see for example if I wanted to look at Tuesday at 4:00 p.m., I would just go up to Tuesday at 4:00 p.m. and it looks like there's 72 commits that were made around that time in this project. And so that's a fairly significant hour. In a less popular project, this would be more significant. Let's go ahead and open up my project so we can see the difference. When we open up this one, you can see that it's a lot simpler because I haven't made many commits to this project, and you can see when I'm making them. Primarily it looks like I'm making them on weekends and maybe a little bit during the week, and that's pretty much what we get there. The pulse of a repository is meant to be a current glimpse into what's been going on recently. It lets you choose a time period to view, and shows some of what's been going on lately. For active projects, the pulse provides useful details, but for inactive projects, the pulse will usually tell you that the project is dead. In that sense, it's like checking for a pulse. You can see the current condition of things. Let's go take a look at one now. I'm sure at this point that you're surprised to see that we're here back at jquery again. This time we're going to take a look at the pulse. In order to do that, we're going to want to click on this link here on the right. That's going to take us over to the Pulse page. You'll remember that I mentioned that we look at a time period, and that sort of gives us an idea of recent activity. By default we're starting out on 1 week. You'll notice that there aren't any active issues, nothing's been closed, nothing's been open, so no new issues coming out. However, there are 3 active pull requests. One of them was merged, and two of them have been proposed. You can also see that we've got some authors contributing, we can see some details about the pull requests. Let's go ahead and take a look at a little bit longer period. So when we set the period out a month, we get quite a few more pieces of information. It seems that there have been a lot more contributions, far more authors over the course of a month versus a week, and there have only been a few more pull requests, but no issues have been entered either. And again, we can see some details about this. Let's see what it looks like on a dead project, like mine. So when we look at this project, you can see that there are 3 pull requests, those are just testing ones that I've been using, a couple of them are from this recording and one of them was just a test. And you can see that it's got a decent amount of information about this. So this project clearly doesn't look very active considering that this is a month, and really it's only been revived in the past 24 hours, so not exactly a thriving open source project here. Using Gists Gists are a great way of sharing code with someone else. It's a place where you can paste your code, but it's got a few additional useful features for you to leverage. The most important thing to know about a gist that you create to share with others is that the gist itself is a Git repository. This means that it's versionable and forkable. That means that you can make modifications to it, just this piece of sample code that you're sharing with someone else, and they can also make their own fork of it and do their own modifications. Let's go create a gist and see how it works. So here we are at GitHub Gist. You'll notice that our URL is not quite GitHub.com, we are actually on a subdomain here. We're going to go ahead and use this to create our first gist. I've got some very, very important precise sample code, it's certainly not lorem ipsum. Oh wait. What I can do here is I can create a gist from this. I'm going to go ahead and create a public gist because I'm not too worried about it. So this gist now exists. This, as I said is a repository. We can comment about it and we can do a number of different things. You'll notice there is a Download button. I can Delete this gist, I can Edit it. So if I edit it I can go in and make any modifications that I want. So I'm just going to go ahead and add that, Update it. You'll notice it's in there now. I can do a number of other things. Looking at the revisions, you can see the changes that have been made. So this is all easily done. You've got all the same other features that you're used to, the starring, and if I change user accounts I'll be able to fork this gist and use it that way. So, this is pretty much a gist. I can then take this and I can actually send someone else a link to this gist and they can use it. Let's jump back to the root again and look at another way of doing this. This time I'm going to go ahead and call this one. (Typing) So once I've made some changes here and set this up, I can go ahead and say Create Secret Gist. Once I do this, that means that you can't just find this one, you actually need to know the URL that you're looking for, but I can share this with anyone else, and then they can see this gist. So, this is just a quick way of sharing a piece of code, you don't want to create a full repository, you just want to toss something out there on the internet and show it to somebody else. Maybe you've got a small section that's causing a bug, maybe you found something interesting. Either way, it's fast, it's easy, and it works pretty well. Profiles and Contributions Do you want to see which other projects someone is watching or contributing to? The Profiles and Contributions information provided by GitHub can be extremely useful for this. If you've been using an open source project, you can use this to find out about other interesting and useful projects. It's one of the best ways to find other useful code. Let's go ahead and see what's in here. So one of the best places to actually track down a good useful bit of information from profiles and see the contributions is to start with an open source project. So here I am back at the jquery project, and I'm going to go ahead and just click on this user here since he's the last person to have authored anything here. So pull up his profile. So this obviously is just the user account page. You'll notice from the URL that it's just the URL minus any project name. And I can see the repositories that this person has contributed to. There's also a graph of his public contributions, which is quite a few as you'll notice down there at the bottom. This is a regular contributor to a number of projects. If I scroll down, you can see some of the activity that he's actually been involved with. We can take a look at his repositories, and so you'll notice that he has a fork of the jquery repository. You can tell the forked ones because of the book icon with the Y on it instead of the regular one. So what I also might notice here is that if I were, say, a jQuery user and I were looking for a unit testing framework in JavaScript, I now know that this qunit exists because I found it here, going from jquery I can see this other one exists. So that's just one useful way to find out about other projects that might exist out there. Lastly, we can take a look at the public activity of this user, and you can just see the commits and comments and other things that he's made recently. So, quite a bit of information. Feel free to go dive in. If you hop on an open source project, you can pick almost any user and you'll find out about quite a few different things that exist. Summary In this module, we looked at quite a few different things dealing with social, open source, and other aspects of GitHub. We looked at how to contribute and customize a project using forking and pull requests to send that information back. We also looked at how we can file issues, reporting them to a project, and from the other end how we can manage those through GitHub. We also looked at viewing information about a project through its graphs, its network graph and getting a sense of what's going on through the pulse. We also looked at how you can share code with others using gists so that you can just send someone a small little sample of code, and they can modify it, you can modify it and make adjustments because it's a repository. And we also looked at how we can find more information about users and additional projects using profiles. Thank you for watching, and I'll see you in my next course. Course author Brendan Enrick Brendan Enrick is an experienced software architect, focusing a great deal of his time on agile and software craftsmanship methodologies. Brendan is a strong proponent of strong development... Course info LevelIntermediate Rating (414) My rating Duration3h 17m Released15 Jul 2014 Share course