git clone -b dev email@example.com:pism/pism.git pism-dev
Please commit all changes to the
dev branch or “topical” branches. The
stable branches, including the current default branch, are managed by PISM developers at UAF. Please feel free to fork the stable branches, however, especially if your changes are peripheral (and are helped by having a non-changing base code).
To change the URL of the PISM repository in an existing clone, see
man git-remote and look for the
set-url command. This might be necessary if you cloned using a read-only URL.
To satisfy our NASA-funded responsibility at UAF, we need to retain some little bit of control. We need PISM to do what we are funded to do. The following list of “best practices” facilitates such minimal control while encouraging healthy development. Perfection on these “rules” is not expected at any time. Mistakes are always forgiven. We are well-protected by version control.
devbranch and not on
stablebranches, because UAF manages stable releases. We do the merge of
devinto the next
stableX.Yrelease. If you find a bug in the stable release then please report it and we will fix it at UAF. Even better, send a pull request if you have fixed it in a fork, or send a patch to firstname.lastname@example.org. If a bug exists in
devand you can safely fix it directly, then that is much appreciated.
cd 'your build directory' make install make test
Proposing and building additional fast-running software tests for the dev branch is strongly encouraged.
git branchwith a name like
issue-XXis a good idea if you need to test before committing. If you are hoping a UAF developer will do something then you might mark it as a ''feature request'' instead of a
The PISM team is currently using a simplified “merge” workflow and not a "pull request" workflow.
If you are just starting with Git, it may not be obvious how to use it to make changes and merge them into the
dev branch at
github.com/pism/pism. See the Git documentation page.
A reasonable principle is this: try to
git pull only into a clean history. If not, you may find you are generating confusing modifications to the history seen by everyone.
Here is one suggested workflow if your first act was (already) to go change some source files in your working copy of
YOU CHANGED FILES foo.cc bar.sh git stash git pull git stash pop RESOLVE ANY CONFLICTS git add foo.cc bar.sh git commit -m "why I changed stuff and how it makes it better" git push
git pull could be replaced by the two steps
git fetch and
git merge origin.
An alternative work flow with the same basic affect as the above is
YOU CHANGED FILES foo.cc bar.sh git add foo.cc bar.sh git commit -m "why I changed stuff and how it makes it better" git status # CHECK FOR OTHER UNCOMMITTED CHANGES (add, commit THEM IF PRESENT) git pull --rebase RESOLVE ANY CONFLICTS AND git add AND git commit FOR FILES WITH FIXED CONFLICTS git push
Finally, a suggested alternative is to create a new 'topic' branch for your changes. Merge the changes in
dev more-or-less frequently in to your new branch, and eventually merge your changes back into
dev once you are done and the new 'topic' branch code has been tested.