Almost done with the tutorial now

doc/src/tutorial_github.txt

@@ -106,7 +106,7 @@ unrelated feature, you should switch branches!
 
 After everything is done, add the files to the branch and commit them:
 
-  $ git add doc/src/tutorial_github.txt :pre
+  $ git add doc/src/tutorial_github.txt
   $ git add doc/src/JPG/tutorial_*.png :pre
 
 [Warning]
@@ -131,8 +131,13 @@ After the commit, the changes can be pushed to the same branch on GitHub:
 $ git push :pre
 
 Git will ask you for your user name and password on GitHub if you have
-not configured anything. If you correctly type your user name and
+not configured anything. If your local branch is not present on Github yet,
-password, the change should be added to your fork on GitHub.
+it will ask you to add it by running
+
+  $ git push --set-upstream origin github-tutorial-update :pre
+
+If you correctly type your user name and
+password, the feature branch should be added to your fork on GitHub.
 
 If you want to make really sure you push to the right repository
 (which is good practice), you can provide it explicitly:
@@ -143,3 +148,88 @@ or using an explicit URL:
 
 $ git push git@github.com:Pakketeretet2/lammps.git :pre
 
+[Filing a pull request]
+Up to this point in the tutorial, all changes were to {your} clones of LAMMPS.
+Eventually, however, you want this feature to be included again upstream.
+To do this, you will want to file a pull request by clicking on the
+"New pull request" button:
+
+:c,image(JPG/tutorial_new_pull_request.png)
+
+Make sure that the current branch is set to the correct one, which, in
+this case, is "github-tutorial-update". If done correctly, the only
+changes you will see are those that were made on this branch.
+
+This will open up a new window that lists changes made to the
+repository. If you are just adding new files, there is not much to do,
+but I suppose merge conflicts are to be resolved here if there are
+changes in existing files. If all changes can automatically be merged,
+green text at the top will say so and you can click the "Create pull
+request" button, see image.
+
+:c,image(JPG/tutorial_create_new_pull_request1.png)
+
+After this you have to specify a short title and a comment with
+details about your pull request. I guess here you write what your
+modifications do and why they should be incorporated upstream. After
+that, click the "Create pull request" button, see image below.
+
+:c,image(JPG/tutorial_create_new_pull_request2.png)
+
+Now just write some nice comments, click "Comment", and that is it. It
+is now up to the maintainer(s) of the upstream repository to
+incorporate the changes into the repository and to close the pull
+request.
+
+:c,image(JPG/tutorial_create_new_pull_request3.png)
+
+:line
+
+[Additional changes]
+
+Before the pull request is accepted, any additional changes you push
+into your repository will automatically become part of the pull
+request.
+
+:line
+
+[After a merge]
+
+When everything is fine the feature branch is merged into the LAMMPS
+repositories:
+
+:c,image(JPG/tutorial_merged.png)
+
+Now one question remains: What to do with the feature branch that got
+merged into upstream?
+
+It is in principle safe to delete them from your own fork. This helps
+keep it a bit more tidy. Note that you first have to switch to another
+branch!
+
+$ git checkout master
+$ git pull master
+$ git branch -d github-tutorial-update :pre
+
+If you do not pull first, it is not really a problem but git will warn
+you at the next statement that you are deleting a local branch that
+was not yet fully merged into HEAD. This is because git does not yet
+know your branch just got merged into lammps-icms upstream. If you
+first delete and then pull, everything should still be fine.
+
+Finally, if you delete the branch locally, you might want to push this
+to your remote(s) as well:
+
+$ git push origin :github-tutorial-update :pre
+
+[Recent changes in the workflow]
+
+Some changes to the workflow are not captured in this tutorial.
+For example, in addition to the master branch, to which all
+new features should be submitted, there is now also an "unstable"
+and a "stable" branch. Furthermore, the naming of the patches
+now follow the pattern "patch_<Day><Month><Year>" so simplify
+comparisons between releases.
+Finally, all patches and submissions are subject to automatic
+testing and code checks to make sure they at the very least
+compile.