Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
In this movie I want to talk about how we can enable collaborators on your project and also how you can become a collaborator to open source project. Now you maybe thinking, well, wait a minute we've already been doing collaboration right? We have our explore_california repository, and we have lynda_version, right? Those are two people collaborating. Well, we have been kind of faking it, because the thing is both of these repositories are logging into GitHub using the same set of credentials, in my case they're both logging in as Kevin Skoglund. So I have two repositories pretending to be two different people, but it's really the same GitHub user.
What if we want other GitHub users to be able to access our project? The way we do that is you go to the project homepage, and you click on Admin, it'll bring up a page here with Collaborators as one of the options, and then we can start typing the GitHub username of the person that we want to collaborate on it. Whatever the person's name is it'll start looking it up. Obviously, I'm not going to add myself to the project, I'm already part of it, but I'm just going to look up my username just to see how it comes up. So there it is, you start typing and it starts narrowing down the Kevin's until finally it finds my username.
You have got to know the person's username or at least be able to find it here, and then once you do, you'll click Add to add them to the project. Once you add them to the project, then GitHub will send them an email telling them that they been added to the repository, and also providing them with this URL here so that they can then clone it and start working. And they'll have the ability to both read and write to that project. So that's an important step in enabling people to be able to work on your project with you. Now if you want to work on an open source project, it works a little bit differently, and the reason why is not everyone in the world can make commits to the actual project itself. It'll be a total free-for-all if everyone could just commit whatever they wanted to the project, instead a limited number of people have write access and can actually make changes to it.
But everyone has read access, so everyone can see it, but not everyone can actually make changes. Instead the way that you make changes is that you need to make a fork. Now before you even make a fork, I suggest the first thing you do is decide what changes you want to make, what contribution do you have to make. Look at the network, make sure that someone else isn't already working on that change, make sure there is not a branch that's dedicated to that change, and look through the issues list to see if someone has posted there about the problem or the feature and maybe has even started a discussion about it.
There's no sense in duplicating someone else's effort. And then it's also good form for you to post an issue there so that other people can see that you've already staked out this territory. The next thing I want to do is make a fork of the project. This will make your own version of the project on your own GitHub repository. It's no longer part of the main one, and this one you will have write access to. So you go ahead and clone the repository, work with it locally just like you normally would, commit those changes up to your version of the project, and then once you got it all done, it's ready to go, you go back to the GitHub page for the main project, and you issue a Pull Request.
Essentially a Pull Request is like raising your hand and saying I have something here that I want to show you. You submit a message with your request so you identify what the problem was that you saw, or what feature you decided you wanted to add, talk about how you want to do it, and why you think it's good for the project, and if you make the case effectively and your code looks good then they will accept your changes and incorporate them into the main project. They'll grab your branch and merge it in. And then at that point, everyone will have access to your new feature. So that's how you can enable collaboration using Git. The process is little different if you're going to give someone else read/write access or if you're going to work on a project where you don't have write access.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.