The technical reason for this is due to the way GitHub tries to hide things behind the scenes for you to make the website easier to use. In order to make a change to a file in a git repository (such as the TravelMapping/UserData repository which contains everyone's list files), you need to have write access so that a commit can be made. Since Jim is the only(?) one with write access, when you use a web browser to edit a file in the TravelMapping/UserData repository, GitHub helpfully creates a fully updated branch (patch-
n where
n increments by one each time you edit your file) in
your fork of the repository. Your fork is a complete copy of the repository under your username (wphackney/UserData here). The branches GitHub creates contain the complete & current history of the TravelMapping/UserData repository at the time they're created so that the branch is completely up-to-date and pull requests won't have conflicts*. For example, wphackney/UserData branch "patch-1" has the first 244 commits to TravelMapping/UserData, branch "patch-2" has the first 464 commits, and "patch-42" has the first 10,517 commits.
You have write access to
your fork of the TravelMapping/UserData repository, so changes you seem to be making to the TravelMapping/UserData repository are actually being committed to these branches patch-
n in your fork. When you finish this editing process and "propose file change" on the web, GitHub hides all the complicated stuff on the backend and automatically lets you submit a pull request of your patch-
n branch back to the TravelMapping/UserData repository.
If instead of going to TravelMapping/UserData and editing your file there, you edit the file in
your fork**, GitHub won't go through this process or may confuse you into creating a new branch in
your fork that generates a pull request to
your fork -- not TravelMapping/UserData. Doubly confusing if you aren't used to git and are used to editing from directly from the TravelMapping/UserData repository is that you will be making changes to an out-of-date branch in your fork due to the way GitHub structures branches. (The default branch GitHub shows you is "master" and GitHub created that the very first time you forked the repository -- being 4 years out of date in wphiii's case.)
So if you are using the web editor for everything, it's an easy mistake to make -- but luckily, easily fixable!
* this is actually (generally) not a problem for TravelMapping/UserData because multiple users don't / a single user from multiple computers doesn't edit a single file so there won't be conflicts -- but GitHub doesn't know this because the workflow is designed for software where multiple users might edit a single a file.
** to be clear -- this is a perfectly valid way to do it (see the manual michih linked to / wrote up) but since there are multiple ways to achieve the same objective with git / GitHub it's not the route wphiii and a few other users have chosen.
