jro_apps/redmine Commit - r5435:1721148bae4f

1

= Contributing to Redmine with git and github

1

= Contributing to Redmine with git and github

2

3

(This is a beta document. If you can improve it, fork it and send a patch/pull request.)

3

(This is a beta document.)

4

5

The ~~official~~ repository is at http://github.com/edavis10/redmine

5

The mirror repository is at http://github.com/edavis10/redmine

6

7

Official branches:

7

Branches:

8

9

* master - is automatically mirrored to svn trunk. ~~DO NOT COMMIT OR MERGE INTO THIS BRANCH~~

9

* master - is automatically mirrored to svn trunk.

10

* [0.6, 0.7, 0.8, 0.9, 1.0,...]-stable - is automatically mirrored to svn release branches. DO NOT COMMIT OR MERGE INTO THIS BRANCH

10

* [0.6, 0.7, 0.8, 0.9, 1.0,...]-stable - is automatically mirrored to svn release branches. DO NOT COMMIT OR MERGE INTO THIS BRANCH

11

* integration-to-svn-trunk - this branch is a git-only branch that will track master (trunk). Any code in here will be eventually merged into master but it may be rebased as any time (git-svn needs to rebase to commit to svn)

12

* integration-to-svn-stable-1.0 - this branch is a git-only branch that will track the 1.0-stable branch in svn. Any code in here will be eventually merged into master and 1.0-stable but it may be rebased as any time (git-svn needs to rebase to commit to svn)

13

14

I (edavis10) might have some other branches on the repository for work in progress.

15

11

16

== Branch naming standards

12

== Branch naming standards

17

13

18

Redmine has two kinds of development:

14

Redmine has two kinds of development:

19

15

20

* bug fixes

16

* bug fixes

21

* new feature development

17

* new feature development

22

18

23

Both bug fixes and new feature development should be done in a branch named after the issue number on Redmine.org. So if you are fixing Issue #6244 your branch should be named:

19

Both bug fixes and new feature development should be done in a branch named after the issue number on Redmine.org. So if you are fixing Issue #6244 your branch should be named:

24

20

25

* 6244

21

* 6244

26

* 6244-sort-people-by-display-name (optional description)

22

* 6244-sort-people-by-display-name (optional description)

27

* issue/6244 (optional "issue" prefix)

23

* issue/6244 (optional "issue" prefix)

28

* issue/6244-sort-people-by-display-name (optional prefix and description)

24

* issue/6244-sort-people-by-display-name (optional prefix and description)

29

25

30

That way when the branch is merged into the Redmine core, the correct issue can be updated.

26

That way when the branch is merged into the Redmine core, the correct issue can be updated.

31

27

32

Longer term feature development might require multiple branches. Just your best judgment and try to keep the issue id in the name.

28

Longer term feature development might require multiple branches. Just your best judgment and try to keep the issue id in the name.

33

29

34

If you don't have an issue for your patch, create an issue on redmine.org and say it's a placeholder issue for your work. Better yet, add a brief overview of what you are working on to the issue and you might get some help with it.

30

If you don't have an issue for your patch, create an issue on redmine.org and say it's a placeholder issue for your work. Better yet, add a brief overview of what you are working on to the issue and you might get some help with it.

35

31

36

== Coding Standards

32

== Coding Standards

37

33

38

Follow the coding standards on the Redmine wiki: http://www.redmine.org/wiki/redmine/Coding_Standards#Commits. Make sure you commit logs conform to the standards, otherwise someone else will have to rewrite them for you and you might lose attribution during the conversion to svn.

34

Follow the coding standards on the Redmine wiki: http://www.redmine.org/wiki/redmine/Coding_Standards#Commits. Make sure you commit logs conform to the standards, otherwise someone else will have to rewrite them for you and you might lose attribution during the conversion to svn.

39

35

40

36

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

             = Contributing to Redmine with git and github
-            (This is a beta document. If you can improve it, fork it and send a patch/pull request.)
+            (This is a beta document.)
-            The official repository is at http://github.com/edavis10/redmine
+            The mirror repository is at http://github.com/edavis10/redmine
-            Official branches:
+            Branches:
-            * master - is automatically mirrored to svn trunk. DO NOT COMMIT OR MERGE INTO THIS BRANCH
+            * master - is automatically mirrored to svn trunk.
             * [0.6, 0.7, 0.8, 0.9, 1.0,...]-stable - is automatically mirrored to svn release branches. DO NOT COMMIT OR MERGE INTO THIS BRANCH
-            * integration-to-svn-trunk - this branch is a git-only branch that will track master (trunk). Any code in here will be eventually merged into master but it may be rebased as any time (git-svn needs to rebase to commit to svn)
-            * integration-to-svn-stable-1.0 - this branch is a git-only branch that will track the 1.0-stable branch in svn.  Any code in here will be eventually merged into master and 1.0-stable but it may be rebased as any time (git-svn needs to rebase to commit to svn)
-            I (edavis10) might have some other branches on the repository for work in progress.
             == Branch naming standards
             Redmine has two kinds of development:
             * bug fixes
             * new feature development
             Both bug fixes and new feature development should be done in a branch named after the issue number on Redmine.org.  So if you are fixing Issue #6244 your branch should be named:
             * 6244
             * 6244-sort-people-by-display-name (optional description)
             * issue/6244 (optional "issue" prefix)
             * issue/6244-sort-people-by-display-name (optional prefix and description)
             That way when the branch is merged into the Redmine core, the correct issue can be updated.
             Longer term feature development might require multiple branches.  Just your best judgment and try to keep the issue id in the name.
             If you don't have an issue for your patch, create an issue on redmine.org and say it's a placeholder issue for your work. Better yet, add a brief overview of what you are working on to the issue and you might get some help with it.
             == Coding Standards
             Follow the coding standards on the Redmine wiki: http://www.redmine.org/wiki/redmine/Coding_Standards#Commits.  Make sure you commit logs conform to the standards, otherwise someone else will have to rewrite them for you and you might lose attribution during the conversion to svn.