Add branching notes for developers and update yaml; delete un-needed …

….gitignore; update .gitignore.

.github/workflows/R-CMD-check.yaml

@@ -2,9 +2,9 @@
 # Need help debugging build failures? Start at https://github.com/r-lib/actions#where-to-find-help
 on:
   push:
-    branches: [main, dev-andy]
+    branches: [main, dev-andy, dev-travis]
   pull_request:
-    branches: [main, dev-andy]
+    branches: [main, dev-andy, dev-travis]
 
 name: R-CMD-check
 

.github/workflows/test-coverage.yaml

@@ -2,9 +2,9 @@
 # Need help debugging build failures? Start at https://github.com/r-lib/actions#where-to-find-help
 on:
   push:
-    branches: [main, dev-andy]
+    branches: [main, dev-andy, dev-travis]
   pull_request:
-    branches: [main, dev-andy]
+    branches: [main, dev-andy, dev-travis]
 
 name: test-coverage
 

README.Rmd

@@ -323,8 +323,84 @@ start of this file.
 expertly designed by Carley Colclough. There is also `inst/pacea-logo-for-printing.jpg`
 for printing purposes.
 
-### Branching
-
-We will add details of how to work on your own branch before merging into the
-main branch, such that the main version is always installable, and guidelines
-for adding to the [NEWS](NEWS.Md).
+### Branching in Git
+
+To ensure the main branch is never broken (and so users can always download the
+package), when editing package code please work on your own branch and then
+merge it in. If just updating the README then we can stick with the main branch
+(because messing something up should not void the package being installable).
+
+Your own branch should be called `dev-yourname`, e.g. `dev-andy` and
+`dev-travis`. If you don't yet have a branch you need to:
+
+- create it locally (and 'check it out', i.e. move into it): `git checkout -b dev-yourname`
+- tell Git where to push to: `git push --set-upstream origin dev-yourname`
+  (Git will tell you this command if you do a `git push` without having run it)
+- update GitHub Actions so that pushes of your branch get properly tested on
+  GitHub. Just add your branch to **both** lists of branches at the top of:
+  - `.github/workflows/R-CMD-check.yaml`
+  - `.github/workflows/test-coverage.yaml`
+
+- Do that as your first commit and push to check everything's working.
+
+Once you have your branch set up then the workflow is:
+
+1. Make sure you are all caught up on the main branch:
+ - `git checkout main`
+ - `git fetch`
+ - `git rebase`
+
+2. Switch to your development branch and merge the main branch into it
+ - `git checkout dev-yourname`
+ - `git merge main`
+
+3. Do some new commits in your branch and push them in the usual way.
+GitHub Actions will work on your branch. TODO verify this:  from the badge code at the top of this file, and the adding of
+the branch in the .yaml, it looks like the R-CMD-CHECK badge
+might check all branches, and so may well fail for an error on the main
+branch. The codecov does specify main so maybe won't change?
+
+4. When you are happy with your changes and ready to merge them into the main
+branch, you need to
+ - add any changes that users should be aware of to the [NEWS](NEWS.Md) file.
+
+No need to mention things that are only of interest to
+developers (like the commiting of these instructions). We want the NEWS to be
+succinct and quickly readable so that people look at it.
+
+Then you need to double check that the main branch is up-to-date with the
+version on GitHub (someone may have pushed some changes since you last fetched),
+then merge any changes back into your branch. You could just check on GitHub (if
+you're the last person to have pushed to main then you are probably fine), or do
+these:
+
+ - `git checkout main`
+ - `git fetch`
+ - `git rebase`
+
+ - `git checkout dev-yourname`
+ - `git merge main`
+
+If that does merge in some new commits then you should
+
+ - `git push`
+to run the GitHub Actions checks again on GitHub. If the merge says something
+like you are all caught up, no merging is needed (i.e. no-one committed anything to
+the main branch recenetly), then no need for the `git push`, since this entire
+step will not have added any new code.
+
+5. Now you are ready to merge your changes into the main branch, so that people
+will get them when they install/update `pacea`:
+ - `git co main`
+ - `git merge dev-andy`
+ - `git push`
+
+And you are done!
+If you want, we have some aliases (such as `git co` for `git checkout` and
+`git p` for `git push` listed in this example .gitconfig file:
+https://raw.githubusercontent.com/quantitative-biology/module-1-git/main/misc/.gitconfig
+from our e-book
+https://www.quantitative-biology.ca/git-and-github.html#save-our-template-.gitconfig-file
+You can put those into your `.gitconfig` file if you like.
+
+This can help understanding on branches: https://www.atlassian.com/git/tutorials/using-branches/git-merge

README.md

@@ -305,8 +305,97 @@ logo.
     designed by Carley Colclough. There is also
     `inst/pacea-logo-for-printing.jpg` for printing purposes.
 
-### Branching
+### Branching in Git
 
-We will add details of how to work on your own branch before merging
-into the main branch, such that the main version is always installable,
-and guidelines for adding to the [NEWS](NEWS.Md).
+To ensure the main branch is never broken (and so users can always
+download the package), when editing package code please work on your own
+branch and then merge it in. If just updating the README then we can
+stick with the main branch (because messing something up should not void
+the package being installable).
+
+Your own branch should be called `dev-yourname`, e.g. `dev-andy` and
+`dev-travis`. If you don’t yet have a branch you need to:
+
+-   create it locally (and ‘check it out’, i.e. move into it):
+    `git checkout -b dev-yourname`
+-   tell Git where to push to:
+    `git push --set-upstream origin dev-yourname` (Git will tell you
+    this command if you do a `git push` without having run it)
+-   update GitHub Actions so that pushes of your branch get properly
+    tested on GitHub. Just add your branch to **both** lists of branches
+    at the top of:
+    -   `.github/workflows/R-CMD-check.yaml`
+    -   `.github/workflows/test-coverage.yaml`
+-   Do that as your first commit and push to check everything’s working.
+
+Once you have your branch set up then the workflow is:
+
+1.  Make sure you are all caught up on the main branch:
+
+-   `git checkout main`
+-   `git fetch`
+-   `git rebase`
+
+2.  Switch to your development branch and merge the main branch into it
+
+-   `git checkout dev-yourname`
+-   `git merge main`
+
+3.  Do some new commits in your branch and push them in the usual way.
+    GitHub Actions will work on your branch. TODO verify this: from the
+    badge code at the top of this file, and the adding of the branch in
+    the .yaml, it looks like the R-CMD-CHECK badge might check all
+    branches, and so may well fail for an error on the main branch. The
+    codecov does specify main so maybe won’t change?
+
+4.  When you are happy with your changes and ready to merge them into
+    the main branch, you need to
+
+-   add any changes that users should be aware of to the [NEWS](NEWS.Md)
+    file.
+
+No need to mention things that are only of interest to developers (like
+the commiting of these instructions). We want the NEWS to be succinct
+and quickly readable so that people look at it.
+
+Then you need to double check that the main branch is up-to-date with
+the version on GitHub (someone may have pushed some changes since you
+last fetched), then merge any changes back into your branch. You could
+just check on GitHub (if you’re the last person to have pushed to main
+then you are probably fine), or do these:
+
+-   `git checkout main`
+
+-   `git fetch`
+
+-   `git rebase`
+
+-   `git checkout dev-yourname`
+
+-   `git merge main`
+
+If that does merge in some new commits then you should
+
+-   `git push` to run the GitHub Actions checks again on GitHub. If the
+    merge says something like you are all caught up, no merging is
+    needed (i.e. no-one committed anything to the main branch
+    recenetly), then no need for the `git push`, since this entire step
+    will not have added any new code.
+
+5.  Now you are ready to merge your changes into the main branch, so
+    that people will get them when they install/update `pacea`:
+
+-   `git co main`
+-   `git merge dev-andy`
+-   `git push`
+
+And you are done! If you want, we have some aliases (such as `git co`
+for `git checkout` and `git p` for `git push` listed in this example
+.gitconfig file:
+<https://raw.githubusercontent.com/quantitative-biology/module-1-git/main/misc/.gitconfig>
+from our e-book
+<https://www.quantitative-biology.ca/git-and-github.html#save-our-template-.gitconfig-file>
+You can put those into your `.gitconfig` file if you like.
+
+This can help understanding on branches:
+<https://www.atlassian.com/git/tutorials/using-branches/git-merge>