1.2 Git Basics: GitHub Pull Requests

Why pull requests? They are a call functionality you should learn in order to make changes to remote Git repositories. It is a means of submitting a change to an existing code base. It doesn't matter if you are a core member of a team or if you fork the repo as an outsider. For beginners, pull requests often seem a little daunting, but they're actually not that complicated. They are part of a workflow that has been very effective for open source contributions. But any team can profit from this kind of workflow. A pull request is simply a proposal of suggested code changes for a team or the maintainer of a code base. People also call this workflow the topic branches workflow. Instead of giving potentially thousands of people push access to repos and manage all that, a fork is self contained by whoever is interested in that project. They can give back the original project by opening a pull request. It's a simple and elegant workflow solution to a complicated problem. GitHub, BitBucket and the likes all support this style of working. In fact, they count on it. The project's maintainer simply check the list of pull requests, and can see who is interested in offering improvements to a particular project. And once a pull request was accepted, often after much discussion, the person with push access can match the suggested changes into the original code base. The permissions are much more manageable like that, especially on big projects with tons of developers involved. The question of cloning or forking comes down to, do you have push access or not? if you don't have push access, you need to fork the project. With the fork, you own that specific copy of a project. If you make any changes, even to a master, it doesn't affect the original code base in any way. Only by a pull request will you be able to submit changes to that original code base, and only if it gets accepted by the maintainers of that code base. It even will be under your username's namespace on GitHub. The cool thing about this fork process is that you have push access right away. On the other hand, if you have that push access to retool, you simply clone the project down to your machine. Cloned or forked, it shouldn't change the workflow. Why? Because pull requests are an excellent way for getting code reviews and feedback. The difference is how you need to set up your project at the start. In both cases, you're pulling down a project on to your machine for development. Both are copies of the project at its latest state off the remote repo. After we fork the project and have our own namespace, and get push access away, we clone the new forked repo down to our machines to apply changes through our preferred code editor. With a project locally cloned, we just need to create a topic branch and apply our changes on it. After we have finished with our work, we need to push the new branch and include the changes up to our forked repo before we can create a pull request. When you have pushed your changes up to your forked remote repo, the pull request is still not finished yet, not even initiated. What you need to do is activate this process via to pull request button in your repo. This is basically a notification to the maintainers of the original repo a request to pull in your suggested changes. This will output a summary of the changes that you want to suggest. Also it gives other people an opportunity to chip in on a conversation about this particular change. It is often the basis for discussion of additional changes or an explanation why something might not be a good fit for a merge. No rocket science really, but maybe a bit intimidating at first. If you are asked to supply additional changes via new comments, you simply work some more on your already used topic branch. Then again, you push your work up to your remote branch. You thereby update the pull request automatically, but don't forget to ping the person who can merge in your work. In the pull request you, the maintainers of the project, and possibly the public will be able to see the diffs this progress would introduce. It's a diff from the master branch in the original call disk and your suggested code changes in your topic branch from your forked repo. After the pull request has been merged, you are given the option to delete the remote branch you were working on. Your local branch from that pull request will be unaffected by that, and it will still be on your machine until you delete it as well. Why not work directly on the master branch? Simple, you push your changes up to your forked repo via focused topic branch because it can be easier merged in that way. If no merge conflicts arise, of course. Also if you would do this work directly in a master branch and your suggested changes would be rejected, you'd end up with obsolete work lying around a master, and you would need to rewind your work on that branch. What about commit messages? If you have a good detailed commit message, you might not need to add additional information when you open the pull request, but you have the option to. If needed, make good use of it. Keep in mind that cryptic descriptions might not work in your favor. There's one question left. How do I update my fork with the changes from the original repo? You will need to add the original repo as a remote upstream repo. That way, you can fetch and pull any changes into your fork to stay up to date. That will keep your fork synchronized, and you can build new stuff on top of the original repo without falling behind or needing to fork the project over and over again.