Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
legTools
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Harbor Registry
Model registry
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
leg
legTools
Commits
f8ec1919
Commit
f8ec1919
authored
9 years ago
by
Fernando Mayer
Browse files
Options
Downloads
Patches
Plain Diff
Initial instructions for contributing
parent
49daee35
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
CONTRIBUTING.md
+43
-0
43 additions, 0 deletions
CONTRIBUTING.md
with
43 additions
and
0 deletions
CONTRIBUTING.md
+
43
−
0
View file @
f8ec1919
# Instructions for contributing
# Instructions for contributing
This guide contains instructions for collaborators to contribute with
the
`legTools`
package.
The general guidelines for contributing to any of the projects in this
GitLab can be found in
[
Boas práticas do uso do Git e GitLab no LEG
][]
(in portuguese only).
## Workflow
In
`legTools`
we use the Gitflow workflow, which can be viewed in this
two links:
[
A successful Git branching model
][]
, and
[
Atlassian tutorial
][]
.
Basically, all the ongoing development is made in the
`devel`
branch. New features and bug fixes are made in additional (parallell)
branches such like
`feature/<num>`
, where
`<num>`
is an incremental
number. Feature branches are merged with the
`devel`
branch. When a new
version is supposed to be ready for release, it is moved to the
`release`
branch, where final tests are made to guarantee it is
stable. Only then it is moved to the
`master`
branch, where it receives
a tag with the version number.
This way, users may opt to install the stable version, from the
`master`
branch, or they may install the development version from the
`devel`
branch.
To contribute to the project, please review the commits in the
`devel`
branch to make sure that what you are trying to do is not already being
done. Then create a new branch, based on the
`devel`
branch, and make
changes in this branch. When you are ready to submit your changes,
please open a Merge Request (MR), and explain in details your
implementation, and how this could be beneficil to the project.
Also, if you're not sure about how to do something, but have an idea for
the project, feel free to open an issue and explain what you want from
there.
<!-- links -->
[
A successful Git branching model
]:
http://nvie.com/posts/a-successful-git-branching-model/
[
Atlassian tutorial
]:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
[
Boas práticas do uso do Git e GitLab no LEG
]:
http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment