The precondition for a successful fork project is, that the fork gets all the patches from the upstream projects. Otherwise the branches are of sync. At the same time, the goal is to not sync the branches so that it make sense to create a fork which looks different. This sounds a bit complicated so let us go into the details of using the git tool for merging different branches.
The first attempt in using only 2 branches was not succesful. The idea was, that the upstream is copied in to the master branch, while the fork is edited in the issue1 branch. The first merge was working fine, but after the second merge some conflicts are the result.
The next next was to use three branches: upstream, master and issue1. This is working much better and it like to explain the idea. The first thing to do is to initialize in a working directory the git repository:
git init
git branch issue1
git branch upstream
git branch
On the screen there are three branches available in which the user can edit. In the upstream branch the snapshot from the wikipedia website are stored. The file article.txt hold the current version which is updated once a month. The upstream is merged into the master branch, and then it's merged into the issue branch. In the issue branch the fork can be edited. Now, the next version of the upstream version is stored in the upstream branch.
And now the magic happens, the user switches to the master branch and executed the following statement:
git merge upstream
git merge issue1
What the git software is doing is to combine the latest upstream version with the fork into a new file. The resulting article.txt contains all the improvements from Wikipedia but it contains also the updates from the fork.
I know, the overall procedure is very complicated because the user has to type in many commands into the terminal. So the prediction is, that some errors will upraise. But in general the idea is to use three branches and merge them into the master branch. In contrast, the upstream branch holds only the upstream version history, which is equal to the timeline of WIkipedia provided in the website.
The chart from the beginning will increase the confusion. What the user needs to know is that he has to copy the latest version of the Wikipedia article into the upstream branch, and commit the changes with “git commit”. It's also important to not delete the branches after merging, because the issue1 branch is the forked version which looks different from the upstream. If the user want's to edit the encyclopedia he is doing so only in the issue1 branch. The master branch is some kind of clearning branch in which the two other branches are combined.