Difference between revisions of " Branches"

From Blazegraph
Jump to: navigation, search
Line 2: Line 2:
 
'''
 
'''
  
= SVN =
+
= git =
  
== Creating a Branch ==
+
== Feature Branches ==
  
Collapse a projectRight click on the project rootTeam => Branch
+
The general model is to create a feature branch from GIT masterThe name of the branch should correspond to the [http://jira.blazegraph.com/ JIRA] ticket number for the feature or defectAn example is below with BLZG-101.  Once the feature is complete, create a Pull Request through GitHub and this will trigger CI and code review.  The JIRA ticket should be updated to reflect the status.
  
Assign a branch name: https://svn.code.sf.net/p/bigdata/code/branches/BRANCH_NAME
+
Feature branch for BLZG-101
 +
git branch BLZG-101
  
Choose NEXT.
+
Track the branch to origin/master
  
Create copy from: HEAD REVISION IN THE REPOSITORY (the current committed code in SVN).
+
git branch -u origin/master BLZG-101
  
Provide a commit message when prompted.
+
Checkout the branch and write the code.
  
Set this flag if you want to start working in the new branch immediately: [x] Switch to new branch
+
git branch checkout BLZG-101
  
Make a note of the revision from which your branch was created.  To do this, use "svn info" at the root of the project of the source branch.  Best to put this revision number in a ticket associated with your branch so that it does not get lost.
+
== Listing and Creating Tags
 
+
Finish.
+
 
+
----
+
 
+
Setting up CI on a branch is also simple.  You need to have the login to jenkins to do this.  Basically, you clone an existing job, change some of the parameters (job name, SVN URL) and let it go.
+
 
+
== Keeping Your Branch Up to Date ==
+
 
+
Collapse on your project branch.  Right click on the project root.  Team => Merge
+
 
+
Choose the two URL option.
+
 
+
Both URLs should be the source branch from which your branch was created.  For example, if your branch was created from the 1.3 maintenance branch, both URLs should point to the 1.3 maintenance branch.
+
 
+
The "from" revision should be the revision at the original branch point or the revision noted from the last time you merged.
+
 
+
The "to" revision should always be HEAD.
+
 
+
When you do this, make a note of the current HEAD revision on the source branch.  To do this, use "svn info" at the root of the project of the source branch.  Best to put this revision number in a ticket associated with your branch so that it does not get lost.  This revision number will be the new "from" revision the next time you do a merge.
+
 
+
= git =
+
  
 
List the tags:
 
List the tags:
Line 48: Line 27:
 
   git tag -a v1.3.3 -m "1.3.3 release"
 
   git tag -a v1.3.3 -m "1.3.3 release"
 
   git push origin v1.3.3
 
   git push origin v1.3.3
 +
 +
= SVN =
 +
 +
SVN is not longer used for Blazegraph.

Revision as of 22:34, 12 July 2015

Most new feature development needs to take place in a branch. This page needs updating for GIT guidelines.

git

Feature Branches

The general model is to create a feature branch from GIT master. The name of the branch should correspond to the JIRA ticket number for the feature or defect. An example is below with BLZG-101. Once the feature is complete, create a Pull Request through GitHub and this will trigger CI and code review. The JIRA ticket should be updated to reflect the status.

Feature branch for BLZG-101

git branch BLZG-101

Track the branch to origin/master

git branch -u origin/master BLZG-101

Checkout the branch and write the code.

git branch checkout BLZG-101

== Listing and Creating Tags

List the tags:

 git tag -l

Tag a release:

 git tag -a v1.3.3 -m "1.3.3 release"
 git push origin v1.3.3

SVN

SVN is not longer used for Blazegraph.