Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
slapos
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Labels
Merge Requests
103
Merge Requests
103
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Jobs
Commits
Open sidebar
nexedi
slapos
Commits
23474349
Commit
23474349
authored
Jun 17, 2011
by
Łukasz Nowak
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Rules need to be defined in another place.
parent
970fd62a
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
0 additions
and
34 deletions
+0
-34
00.Repository.Rules.txt
00.Repository.Rules.txt
+0
-34
No files found.
00.Repository.Rules.txt
deleted
100644 → 0
View file @
970fd62a
SlapOS repository rules
=======================
Short version for impatient
---------------------------
'master' branch is always stable. One shall never work in this branch. One
shall expect reversion or removal of his commits in 'master' branch, if they
are not because of merging another branch.
Everyone has to create branch, basing on 'master' or any other branch. All
work shall be done in such branch. It is advised to review it before merging
into 'master'. It is very good habit to tag such merges.
A bit more background
---------------------
SlapOS repository 'master' branch is supposed to be stable. No new work is
accepted on this branch. Each time someone uses (clones, extends) 'master'
branch it is supposed to work (as far as it was tested).
Tags on 'master' branch are supposed to be repeatable software definitions
forever. All versions and external links shall be setup in a way, that they
wouldn't change in day, month, year, etc.
Everyone can make his own branch to introduce new software to SlapOS. There
are no rules about those branches, as each software is specific.
It is good idea to ask for review before merging changes into 'master' branch.
Peer review can detect issues not detected by testing, development or self
analysis.
After some software is stabilised and no more work is planned it is acceptable
to remove such abandoned branch in order to minimise amount of branches.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment