Differences

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

--- git-for-lieutenants [2012/11/02 17:20] – smilauer
+++ git-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:
@@ Line 14: / Line 14: @@
 ====== Reference repository ======
 On the reference repository, two main branches exist:
-  * ''master'' -  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.**
+  * ''master'' -  this branch is used for development.
-  * ''develop'' - used for development.
+  * ''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 ''develop'' 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:
@@ Line 23: / Line 23: @@
   # clone reference repo
   $ git clone http://www.oofem.org/git/oofem.git oofem.git
+  # Note: when a repository is cloned, git automatically creates a master branch that tracks origin/master
   $ cd oofem.git
-  # track remote develop branch on reference repo; it will became active one
-  $ git checkout -b develop origin/develop
   # create a new brach for a new development
   $ git checkout -b featureA
@@ Line 38: / Line 37: @@
 The user use git format-patch to generate the mbox-formatted files.
 ====== 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 develop 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:
     #create a feature branch
-    $ git branch c_name/featureA develop
+    $ git branch c_name/featureA master
     # and to switch into this branch
-    #git branch c_name/featureA
+    $ git checkout c_name/featureA
 Or, if you want to also switch to it immediately, you can use the checkout -b option:
-    $ git checkout -b c_name/featureA develop
+    $ git checkout -b c_name/featureA master
 Now you’re ready to add contributed work into this topic branch and determine if you want to merge it into reference longer-term develop branch.
@@ Line 92: / Line 91: @@
 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.
-For example, once you merged all patches to a ''develop'' branch on a local machine, push the local ''develop'' branch to the server via
+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 push origin develop
+   $ 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
+   $ git push origin master
+Finally, the c_name/featureA branch can be deleted
+   $ git branch -d c_name/featureA
 ====== Merging workflow ======
-In oofem project, we have two long-running branches, master and develop. ''Master'' is updated only when a very stable release is cut and all new code is integrated into the ''develop'' branch. Each time you have a new topic branch to merge in, you merge it into ''develop''.
+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''.