Following PETSc development
The default branch in the PETSc repository is named master.
It contains all features and bug fixes that are believed to be stable and will be in the next release.
Users developing software based on recently-added features in PETSc should follow
$ git clone https://bitbucket.org/petsc/petsc $ cd petsc $ git pull # to get updates
Features that are still experimental will be in the next branch.
To use these features, and perhaps influence their design, follow
next and discuss your concerns on the petsc-dev mailing list or by commenting on commits. After cloning, use
$ git checkout next $ git pull # to get updates
git checkout master to get back to the more stable version.
Production users can follow the maint branch, which contains the latest maintenance release plus any additional bug fixes. It should always be more stable than the latest tarball.
Contributing to PETSc
By submitting code, the contributor gives irretrievable consent to the redistribution and/or modification of the contributed source code as described in the PETSc open source license.
Please read the code standards chapter of the developer guide before sending patches.
The recommended way is to provide pull-requests via a fork of the PETSc repository.
*For very small changes you can clone the petsc repository, create a new branch on your local repository from master, apply and commit your changes there, and use
git format-patch origin/master to create the patch. Send the patch to firstname.lastname@example.org.
PETSc Development Workflow
If you have direct write (push) access to the PETSc repository, you should be familiar with our development workflow. We use a simplified version of the
next workflow used by the Linux kernel developers. This allows parallel development of multiple features at the same time while preserving a stable
master branch. The model is explained in gitworkflows(7) (but we do not currently use a
"Git commands are like irregular verbs in a foreign language: there’s no all-encompassing logic to them, you just have to memorize which words you need for each thing you want to express."
"Git is the perl of revision control systems."
"A mistake most beginning git users make is thinking git is a complete revision control system; it is not. Git, plus an organized mailing list that people actually respond to action items on, plus a rigid set of stylized bookkeeping done by each developer, plus a tyrannical manager of the entire software development process is a complete revision control system."