oofem-wiki

User Tools

Site Tools

Trace:
git-for-lieutenants

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
git-for-lieutenants [2012/12/19 10:34] – [Applying Patches from E-mail] milangit-for-lieutenants [2013/05/03 11:07] – Added section on merging branches bp
Line 1: Line 1:
-This page contains an instructions and guidelines for lieutenants. Lieutenants are experianced developpers and maintainers, usually in charge of a specific subsystem of the project and they merge in changes from individual developpers and push to the reference (blessed) repository that everyone then clones from again. +This page contains an instructions and guidelines for lieutenants. Lieutenants are experienced developers and maintainers, usually in charge of a specific subsystem of the project and they merge in changes from individual developers and push to the reference (blessed) repository that everyone then clones from again. 
  
 :!: Remember: As Lieutenant you are responsible for the project, so you have to make sure, that the contributed work meets all requirements: :!: Remember: As Lieutenant you are responsible for the project, so you have to make sure, that the contributed work meets all requirements:
Line 17: Line 17:
   * ''stable'' -  this branch is stable and should be in a state that allow a release at any time. **Please do not merge any changes into this branch.**   * ''stable'' -  this branch is stable and should be in a state that allow a release at any time. **Please do not merge any changes into this branch.**
  
-Individual developpers typically clone the main repository, create a topic branch, derived from ''master'' branch of the main repository and make their development there. Then they create a patch or patch series they are planning to contribute. **Basically, the same procedure is followed by Lieutenants for their own development, except they do not have to send patches to themselfs.**+Individual developers typically clone the main repository, create a topic branch, derived from ''master'' branch of the main repository and make their development there. Then they create a patch or patch series they are planning to contribute. **Basically, the same procedure is followed by Lieutenants for their own development, except they do not have to send patches to themselves.**
  
 The sequence looks basically like this: The sequence looks basically like this:
Line 37: Line 37:
 The user use git format-patch to generate the mbox-formatted files. The user use git format-patch to generate the mbox-formatted files.
 ====== Applying Patches from E-mail ====== ====== Applying Patches from E-mail ======
-If you receive a patch over e-mail that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. Please see detailed descption of this topic in [[http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project|Git book]].+If you receive a patch over e-mail that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. Please see detailed description of this topic in [[http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project|Git book]].
  
 The Lieutenants of the Git project tends to namespace these branches as well — such as c_name/featureA, where c_name is short for the person who contributed the work. As you’ll remember, you can create the branch based off your master branch like this: The Lieutenants of the Git project tends to namespace these branches as well — such as c_name/featureA, where c_name is short for the person who contributed the work. As you’ll remember, you can create the branch based off your master branch like this:
Line 90: Line 90:
  
 When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a develop reference branch. When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a develop reference branch.
 +
 +To merge changes made in c_name/featureA branch into the master branch, switch to master branch first and then merge c_name/featureA branch into it
 +
 +   $ git checkout master
 +   $ git merge c_name/featureA
  
 For example, once you merged all patches to a ''master'' branch on a local machine, push the local ''master'' branch to the server via For example, once you merged all patches to a ''master'' branch on a local machine, push the local ''master'' branch to the server via
Line 95: Line 100:
    $ git push origin master    $ git push origin master
  
 +Finally, the c_name/featureA branch can be deleted
  
 +   $ git branch -d c_name/featureA
 ====== Merging workflow ====== ====== Merging workflow ======
 In oofem project, we have two long-running branches, master and stable. ''stable'' is updated only when a very stable release is cut and all new code is integrated into the ''master'' branch. Each time you have a new topic branch to merge in, you merge it into ''master''. In oofem project, we have two long-running branches, master and stable. ''stable'' is updated only when a very stable release is cut and all new code is integrated into the ''master'' branch. Each time you have a new topic branch to merge in, you merge it into ''master''.
  
git-for-lieutenants.txt · Last modified: 2017/11/01 09:23 by bp