Changes between Version 5 and Version 6 of DRM4G/Development
- Timestamp:
- Dec 7, 2016 3:36:27 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DRM4G/Development
v5 v6 32 32 33 33 34 From here you should create branches for every new feature you'd like to include to the DRM4G.34 From here you should follow our [wiki:DRM4G/Development#OurGitworkflow gitflow] and create branches for every new feature you'd like to include to the DRM4G. 35 35 * To create a new branch and switch to it you can use the command `git checkout -b <branch_name>`. 36 36 * For a more in depth tutorial on how branching works, click [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging here]. … … 107 107 As mentioned above, to us, our ''central'' repository will be a private one hosted by '''''!GitBucket''''', but in addition we have a second public one hosted in '''''!GitHub''''' to make the DRM4G accessible to anyone that might want to contribute to the project. 108 108 109 To add the '''!GitHub''' repository as a new remote: 110 111 {{{#!sh 112 git remote add github https://github.com/SantanderMetGroup/DRM4G.git 113 }}} 114 109 115 Both this two repositories have at least two branches, the '''master''' and the '''develop''' branches, that must be synchronized at all times. 110 116 * Commits in the '''master''' branch represent all the stable versions of the DRM4G. This means that merges to this branch are only done when ready to publish a release. … … 112 118 * The '''develop''' branch reflects the whole evolution of the project. It shows all of the new features and bug fixes that have been included. This is the main branch where all of the work will be done. 113 119 120 If during development, you find yourself working in a team and wish to share your code, push your work to our ''central'' repository in ''!GitBucket'', not ''!GitHub''. 121 {{{#!sh 122 git push -u origin <branch_name> 123 }}} 124 Something to remember then, is that when you've finished your work on the branch, you musn't forget to eliminate it from the remote repository. 125 {{{#!sh 126 git branch -d <branch_name> #deletes the branch from your local repository 127 git push origin :<branch_name> #deletes the same branch from the remote repository 128 }}} 114 129 115 130 === Adding new features === 116 131 117 Each time some big change or a new feature is going to be implemented, a new branch has to be created from the '''develop''' branch 132 Each time __some big change__ or __new feature__ is going to be implemented, a new '''__feature branch__''' has to be created from the '''develop''' branch. 133 134 The '''feature branches''' are how new functionalities are introduced and [wiki:DRM4G/Development#TestingtheDRM4G tested]. Normally the finalization of one of them will also define when a new release will be published, but that's not always the case since a new release may include more than one new feature. 135 136 * As for the naming convention for these branches, they can be anything separated by hyphens ("'''-'''"), but always adding the prefix "'''DRM4G-'''". 137 * However the name should try to be describe what is being implemented with it. 138 139 {{{#!sh 140 git checkout develop 141 git checkout -b DRM4G-new-feature #it will switch you to the new branch 142 }}} 143 144 When finished, the branch __has to be merged back into the '''develop''' branch__. After it can be deleted. 145 * To keep the history of the branches created, the merges to the '''develop''' branch, will always be done with the no fast-forward option "'''--no-ff'''". 146 147 {{{#!comment 148 Before merging, maybe it would be advisable to merge the '''develop''' branch into the '''feature branch''', to verify that all the changes work well, at least in the case where further changes have been done to the '''develop''' since the '''feature branch''' was created. Then if everything goes well merge the '''feature branch''' into the '''develop''' branch. 149 }}} 150 151 {{{#!sh 152 git checkout develop 153 git merge --no-ff DRM4G-new-feature 154 git branch -d DRM4G-new-feature 155 git push origin develop 156 git push github develop 157 }}} 158 118 159 119 160 … … 160 201 }}} 161 202 203 Aferwards you can just delete the '''release branch'''. 204 {{{#!sh 205 git branch -d DRM4G-X.X.X 206 }}} 207 208 162 209 163 210 === Hotfixes === 164 211 165 As an exception to the normal flow of the development, in the cases when an important error is discovered only after the release has been published, a branchcan be created from the '''master''' to fix it.212 As an exception to the normal flow of the development, in the cases when an important error is discovered only after the release has been published, a '''__hotfix branch__''' can be created from the '''master''' to fix it. 166 213 * This is done like this as to not disrupt the teams working on the '''develop''' branch. 167 214 * The nomenclature followed would be '''__hotfix-MAJOR.MINOR.PATCH__''' … … 169 216 * All of the files would have to have their version numbers modified. 170 217 171 After the problem was solved, you'd have to follow the instructions [wiki:DRM4G/Development#Gettingreadyforarelease to p ublisha new release], except considering the '''hotfix branch''' to be the '''release branch'''.218 After the problem was solved, you'd have to follow the instructions [wiki:DRM4G/Development#Gettingreadyforarelease to prepare for a new release], except considering the '''hotfix branch''' to be the '''release branch'''. 172 219 * That means that a new release branch shouldn't be created. But this branch would have to be merged back into the '''master''' and the '''develop''' branch following the instructions set in the previous section. 173 220