Branches
A branch is a separate development stream in Git. Imagine a project on which multiple people are working. It would be usual to have a branch representing the core of the software, another for the user interface, another for a particular job the code does, etc. As the project progresses, code from the separate branches would be merged into the main "master" branch (the default normally created by GitHub). Whenever anyone building a branch is happy it will work nicely as part of the main code (for example, it passes Unit Tests that say it's interface methods work fine), they would issue a "pull request", and the core software team or manager would then accept that request, merge in the code, and resolve any issues.
The advantage with branches is we can isolate developing code that might be unfinished or otherwise broken, from the core software. If the latter is reserved for working code, people can safely download it. That's not to say we wouldn't also have a release version: master branches are still, more often than not, unfinished code, but at least we know it is likely to be unbroken code.
In order to use this functionality, we need to understand how to make a new branch, and how to issue a pull request.
For this example run-through, we'll use the following files: latlong.py and testlatlong.py. Download these into a new directory and set it up as a GitHub repo using GitHub Desktop (if you're not sure how to do this, there's a full practical on GitHub you should work through before doing this practice). We've called our repo LatLong in the below. Push it up to GitHub.
When you push code to GitHub, by default it goes to the master branch. To make a new branch, go to the GitHub website and open the repo site. You should be in the "master" branch if you haven't created any others. We'll now make another. Click on the branch drop-down list (see image, below), and type in a new branch name development. Press ENTER at the end of it to create the branch.
The new branch will automatically copies the master branch. Now go to the files on your harddrive and adjust one by adding a comment. In GitHub Desktop, you should see the change. Before you commit it click on the Current branch drop-down (image below) and select development.
You should see the commit button change to Commit to development. Push the button to commit, and then sync the code online with a push to GitHub. If you now go to GitHub and refresh the page you'll see that the code has synced with the development branch, but if you use the branch drop-down to switch to master, you won't see the file change.
We're now free of the master branch and submitting to the development branch. As we're the repo owner and we haven't set any restrictions, we could still push to master if we liked, but we're not going to. If we were working with others, we could set restrictions to stop people pushing to the master if we wanted, and this would be usual (instructions).
We can now imagine we'd continue to develop the devlopment branch until we were happy it was ready to be merged with the master branch (and passed all the relevant tests!). What we need to do is issue a "pull request". As it happens, as we're owner, this will come to us, but if the owner was someone else, it would go to them.
In GitHub Desktop, click on the Branch menu, and select Create pull request. This will take you to the website where you can do this and prepare it for a new request. You can get to this directly at the website from the Pull requests tab at the top of the repo, which is where, as owner, you'd also merge the pull requests into master, as we'll see. NB: If you don't see the heading Open a pull request, there's probably no difference between your code and the master.
Change the pull request name to something explaning what you've changed and add appropriate comments, then press Create pull request. As you're the owner you'll see the pull request almost instantly arrive with information about any conflicts with master (see image below). We shouldn't have any that need resolving.
If you click the dropdown next to the merge button, you should see a series of options. We want to merge all commits, which is the default, so push the Merge pull request button without changing anything and push Confirm merge when asked.
If you now go to the master branch on the website, you should now see it has picked up the changed file commit.
And that's it, pretty much. If there are any problems with merging your code, because, for example, there are conflicts in files edited by more than one person, you'll need, as owner, to resolve the issues, deciding what code to keep. For information on how to do this, see the addressing merge conflicts page. There's a lot more you can do with GitHub to manage the interaction of branches and multiple developers with different levels of access; see the pull request information page for more.
Overall, then, a repository system like GitHub can help us to manage bugs by limited their injection into core code, meaning the core code should stay, more or less, reliable.