Changes between Version 5 and Version 6 of DRM4G/Development


Ignore:
Timestamp:
Dec 7, 2016 3:36:27 PM (5 years ago)
Author:
minondoa
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DRM4G/Development

    v5 v6  
    3232
    3333
    34 From here you should create branches for every new feature you'd like to include to the DRM4G.
     34From 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.
    3535* To create a new branch and switch to it you can use the command `git checkout -b <branch_name>`.
    3636* 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].
     
    107107As 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.
    108108
     109To add the '''!GitHub''' repository as a new remote:
     110
     111{{{#!sh
     112git remote add github https://github.com/SantanderMetGroup/DRM4G.git
     113}}}
     114
    109115Both this two repositories have at least two branches, the '''master''' and the '''develop''' branches, that must be synchronized at all times.
    110116* 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.
     
    112118* 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.
    113119
     120If 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
     122git push -u origin <branch_name>
     123}}}
     124Something 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
     126git branch -d <branch_name> #deletes the branch from your local repository
     127git push origin :<branch_name> #deletes the same branch from the remote repository
     128}}}
    114129
    115130=== Adding new features ===
    116131
    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
     132Each 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
     134The '''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
     140git checkout develop
     141git checkout -b DRM4G-new-feature #it will switch you to the new branch
     142}}}
     143
     144When 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
     148Before 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
     152git checkout develop
     153git merge --no-ff DRM4G-new-feature
     154git branch -d DRM4G-new-feature
     155git push origin develop
     156git push github develop
     157}}}
     158
    118159
    119160
     
    160201}}}
    161202
     203Aferwards you can just delete the '''release branch'''.
     204{{{#!sh
     205git branch -d DRM4G-X.X.X
     206}}}
     207
     208
    162209
    163210=== Hotfixes ===
    164211
    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 branch can be created from the '''master''' to fix it.
     212As 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.
    166213 * This is done like this as to not disrupt the teams working on the '''develop''' branch.
    167214 * The nomenclature followed would be '''__hotfix-MAJOR.MINOR.PATCH__'''
     
    169216  * All of the files would have to have their version numbers modified.
    170217
    171 After the problem was solved, you'd have to follow the instructions [wiki:DRM4G/Development#Gettingreadyforarelease to publish a new release], except considering the '''hotfix branch''' to be the '''release branch'''.
     218After 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'''.
    172219* 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.
    173220