-
Notifications
You must be signed in to change notification settings - Fork 564
VC (VERSION CONTROL)
The Trilinos github repository contains several long-lived branches:
-
develop: The main development branch that Trilinos developers issue pull request to in order to add new features, fix bugs, etc.
-
Who pulls from this branch?
- Close collaborators and customers that want to help test (not use) new features as they are being developed
- Very close collaborators that want to have access to the very latest development version of Trilinos who don't mind dealing with more defects and increased instability
-
Who pulls from this branch?
-
master: A relatively stable version of Trilinos that is updated from the 'develop' branch when a specific set of builds for a specific set of packages have 100% passing tests
-
Who pulls from this branch?
- Close collaborators and users who want to access a very recent yet fairly stable version of Trilinos
-
Who pulls from this branch?
-
trilinos-release-X-Y-branch: Branch for the maintenance of the set of Trilinos X.Y.Z releases. Official releases of Trilinos are tagged on this branch using the tag name trilinos-release-X-Y-Z
-
Who pulls from this branch?
- External users that need named and supported versions of Trilinos with minimal-change patch releases for bug fixes (Note, users only should access tagged releases
trilinos-release-X-Y-Z
and not just pull from the tip of a release branch).
- External users that need named and supported versions of Trilinos with minimal-change patch releases for bug fixes (Note, users only should access tagged releases
-
Who pulls from this branch?
The following links provide information on Trilinos version control processes and workflows.
- See How to Do Version Control with Git in Your CSE Project (an IDEAS Productivity "How To" Document).
- Do an initial setup to use git on any new machine.
- Use the simple centralized workflow to integrate and push changes to a shared remote tracking branch (i.e. the 'develop' branch).
- For typical development, most developers will checkout, make changes, and push changes to the 'develop' branch.
- To fix defects on a release branch, use the release branch merge workflow.
Copyright © Trilinos a Series of LF Projects, LLC
For web site terms of use, trademark policy and other project policies please see https://lfprojects.org.
Trilinos Developer Home
Trilinos Package Owners
Policies
New Developers
Trilinos PR/CR
Productivity++
Support Policy
Test Dashboard Policy
Testing Policy
Managing Issues
New Issue Quick Ref
Handling Stale Issues and Pull Requests
Release Notes
Software Quality Plan
Proposing a New Package
Guidance on Copyrights and Licenses
Tools
CMake
Doxygen
git
GitHub Notifications
Mail lists
Clang-format
Version Control
Initial git setup
'feature'/'develop'/'master' (cheatsheet)
Simple centralized workflow
Building
SEMS Dev Env
Mac OS X
ATDM Platforms
Containers
Development Tips
Automated Workflows
Testing
Test Harness
Pull Request Testing
Submitting a Pull Request
Pull Request Workflow
Reproducing PR Errors
Addressing Test Failures
Trilinos Status Table Archive
Pre-push (Checkin) Testing
Remote pull/test/push
PR Creation & Approval Guidelines for Tpetra, Ifpack2, and MueLu Developers