The Complete Beginner's Guide to GitHub

Thus far, we’ve only dealt with one way of moving code from one branch of a GitHub repo to another: by merging the branches. This is by far the most common way that code moves from one branch to another, but it is not the only way. In particular, merging is generally used to move code from feature branches back into the main. Let’s now look at rebasing , a way of moving code from the main branch into a feature branch. Rebasing a Branch Rebasing allows you to update your feature branch to reflect changes that have been made to the main branch since the feature branch was created. If, for example, another developer commits changes onto the main branch that affect the same functionality you’re changing in your feature branch, you can rebase your feature branch so that the feature branch includes that other developer’s changes. This lets you ensure that your changes will work correctly with the code on the most up-to-date version of the main branch, not just with...

In the previous post, we discussed the basic GitHub workflow: create a feature branch, do work on the feature branch (committing changes as you go), push the feature branch, create a merge request, and pull the updated code once the merge request is accepted. In the push step and the pull step, we interface between our local copy of the repository and the copy of the repository maintained on GitHub.com (the remote repository ). Let’s go into more detail about remote repositories and how GitHub Desktop can interact with them. Public and Private Repositories Log into GitHub.com. You should see a list of your repositories in the left-hand sidebar. If you hover over the desktop-tutorial repository we created in the last post, you should see that GitHub automatically created it as a private repository , meaning that only you and anyone to whom you explicitly grant access can see the repository and the code it contains. Let’s create a new repository on GitHub.com. Click t...