Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
A
Actor Framework
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Metrics
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
cpp-libs
Actor Framework
Commits
b950901e
Commit
b950901e
authored
Mar 09, 2015
by
Dominik Charousset
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add Git Guide to HACKING.md
Close #163
parent
baf0679b
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
54 additions
and
1 deletion
+54
-1
HACKING.md
HACKING.md
+54
-1
No files found.
HACKING.md
View file @
b950901e
...
...
@@ -238,6 +238,17 @@ Naming
};
```
-
Use
`T`
for generic, unconstrained template parameters and
`x`
for generic function arguments. Suffix both with
`s`
for
template parameter packs:
```
cpp
template
<
class
...
Ts
>
void
print
(
const
Ts
&
...
xs
)
{
// ...
}
```
Headers
=======
...
...
@@ -349,7 +360,7 @@ extra rules for formatting metaprogramming code.
```
Rvalue
r
eferences
Rvalue
R
eferences
=================
-
Use rvalue references whenever it makes sense.
...
...
@@ -364,3 +375,45 @@ Preprocessor Macros
functions or proper constants.
-
Macro names use the form
`CAF_<COMPONENT>_<NAME>`
.
General Git Rules
=================
-
The first line is a capitalized summary and has at most 50 characters.
-
The second line is left empty.
-
Optional long descriptions begin on the third line with a at most 72
characters per line.
-
Write commit messages in the imperative: "Fix bug" and not "Fixes bug"
or "Fixed bug".
Git Branches and Work Flow
==========================
-
The
`master`
branch always reflects a
*production-ready*
state, i.e.,
the latest release version.
-
The
`develop`
branch is the main branch. Every time it reaches a stable
point it is merged back to
`master`
for a new release. The
`develop`
branch
reflects the latest state of development and should always compile.
-
Simple bugfixes consisting of a single commit can be pushed to
`develop`
.
-
Fixes for critical issues can be pushed to the
`master`
(and
`develop`
)
branch after talking to the maintainer
(and then cause a new release immediately).
-
New features or non-trivial fixes are developed in a
*topic branch*
using
the naming convention
`topic/short-description`
. Topic branches are merged
off from
`develop`
. Finishing topic branches includes these steps:
+
Create a
*pull request*
to
`develop`
on GitHub
+
Wait for the results of Jenkins and fix any issues that might come up
+
Squash your commits if necessary once Jenkins succeeds
+
Ask the maintainer to review your changes if you have green light from
Jenkins and a clean Git history for your work
+
The maintainer will merge the topic branch back into
`develop`
after the
review phase is done (and you once again have a clean Git history)
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