SWGANH Development Process - Revision history

Apathy: /* TL:DR For Bash Users */

2010-04-06T16:17:55Z

‎TL:DR For Bash Users

Apathy: /* Use Case: Peer Reviewing a Bug Fix */

2010-04-06T16:17:40Z

‎Use Case: Peer Reviewing a Bug Fix

Apathy: /* TL:DR for Bash Users */

2010-04-06T16:15:02Z

‎TL:DR for Bash Users

Apathy at 16:14, 6 April 2010

2010-04-06T16:14:00Z

Apathy at 16:13, 6 April 2010

2010-04-06T16:13:39Z

Apathy: /* Use Case: Fixing a Bug From Mantis */

2010-04-06T16:13:00Z

‎Use Case: Fixing a Bug From Mantis

Apathy: /* Use Case: Fixing a Bug From Mantis */

2010-04-06T16:07:06Z

‎Use Case: Fixing a Bug From Mantis

Apathy: /* Use Case: Fixing a Bug From Mantis */

2010-04-06T16:04:41Z

‎Use Case: Fixing a Bug From Mantis

Apathy: /* Use Case: Peer Reviewing a Bug Fix */

2010-04-06T15:07:29Z

‎Use Case: Peer Reviewing a Bug Fix

Apathy at 15:05, 6 April 2010

2010-04-06T15:05:43Z

@@ Line 151: / Line 151: @@
 In the above diff we note a slight error in the last commit that the original developer overlooked, the log statement has used a %d placeholder used for printing out numbers while a string was passed as an argument. This highlights the point of performing peer reviews, to help in catching mistakes before they ever make it to the main testing branch. Now the reviewer can point out this issue to the original developer who can then implement the necessary fix. Once that's done the issue can be considered to have passed review and the mantis ticket can be updated to state that the fix is ready to be merged into the main testing branch.
-=== TL:DR For Bash Users ===
+=== TL:DR for Bash Users ===
 To do the above in the Bash prompt run the following:

← Older revision		Revision as of 16:17, 6 April 2010
Line 150:		Line 150:

	In the above diff we note a slight error in the last commit that the original developer overlooked, the log statement has used a %d placeholder used for printing out numbers while a string was passed as an argument. This highlights the point of performing peer reviews, to help in catching mistakes before they ever make it to the main testing branch. Now the reviewer can point out this issue to the original developer who can then implement the necessary fix. Once that's done the issue can be considered to have passed review and the mantis ticket can be updated to state that the fix is ready to be merged into the main testing branch.		In the above diff we note a slight error in the last commit that the original developer overlooked, the log statement has used a %d placeholder used for printing out numbers while a string was passed as an argument. This highlights the point of performing peer reviews, to help in catching mistakes before they ever make it to the main testing branch. Now the reviewer can point out this issue to the original developer who can then implement the necessary fix. Once that's done the issue can be considered to have passed review and the mantis ticket can be updated to state that the fix is ready to be merged into the main testing branch.
		+
		+	=== TL:DR For Bash Users ===
		+
		+	To do the above in the Bash prompt run the following:
		+
		+	1) Do a pull to grab the latest code
		+	<code>
		+	git pull
		+	</code>
		+
		+	2) Checkout the bug branch
		+	<code>
		+	git checkout issue0000001
		+	</code>
		+
		+	3) Display the diff of the last X changes relevant to the fix
		+	<code>
		+	git diff HEAD~X
		+	</code>

@@ Line 128: / Line 128: @@
 <code>
   git commit -m "Log message"
-</code>
+[or to commit all changed files without explicitly adding them run]
-−
-To commit all changed files without explicitly adding them run:
-<code>
   git commit -a -m "Log message"
 </code>

← Older revision		Revision as of 16:14, 6 April 2010
Line 6:		Line 6:

	Many terms found in the article are used in the below documentation such as develop, feature and hotfix branches. Please refer back to the above if further clarification on such terms is needed. Below is the overview image from the above article kept here for easy reference while reading the rest of this document.		Many terms found in the article are used in the below documentation such as develop, feature and hotfix branches. Please refer back to the above if further clarification on such terms is needed. Below is the overview image from the above article kept here for easy reference while reading the rest of this document.
		+
	[[Image:GitWorkflow.png]]		[[Image:GitWorkflow.png]]

@@ Line 103: / Line 103: @@
 By default the current branch should be selected, if not select the current branch and make sure the Remote Destination Repository is set to '''origin''' and that all options in the Transfer Options are unchecked, then hit the Push button. That's it, now the fix is ready for review! Update the related mantis ticket and head to the IRC channel to find a core developer to assist with the Peer Review.
-== TL:DR for Bash Users ==
+=== TL:DR for Bash Users ===
 If using the command line the below is a simplified version of the above workflow:

← Older revision		Revision as of 16:13, 6 April 2010
Line 102:		Line 102:

	By default the current branch should be selected, if not select the current branch and make sure the Remote Destination Repository is set to '''origin''' and that all options in the Transfer Options are unchecked, then hit the Push button. That's it, now the fix is ready for review! Update the related mantis ticket and head to the IRC channel to find a core developer to assist with the Peer Review.		By default the current branch should be selected, if not select the current branch and make sure the Remote Destination Repository is set to '''origin''' and that all options in the Transfer Options are unchecked, then hit the Push button. That's it, now the fix is ready for review! Update the related mantis ticket and head to the IRC channel to find a core developer to assist with the Peer Review.
		+
		+	== TL:DR for Bash Users ==
		+
		+	If using the command line the below is a simplified version of the above workflow:
		+
		+	1) Create a new branch of of develop for the change:
		+	<code>
		+	git checkout -b issue0000001 develop
		+	</code>
		+
		+	2) List modifications:
		+	<code>
		+	git status
		+	</code>
		+
		+	3) Add changes to staging area
		+	<code>
		+	git add .
		+	[or]
		+	git add path/to/filename
		+	</code>
		+
		+	4) Commit code
		+	<code>
		+	git commit -m "Log message"
		+	</code>
		+
		+	To commit all changed files without explicitly adding them run:
		+	<code>
		+	git commit -a -m "Log message"
		+	</code>
		+
		+	5) Finally push the changes on up
		+	<code>
		+	git push origin issue0000001
		+	</code>

	== Use Case: Peer Reviewing a Bug Fix ==		== Use Case: Peer Reviewing a Bug Fix ==

@@ Line 91: / Line 91: @@
 [[Image:DevProcessBugfix4.png]]
-NOTE: If the change that's being committed is to fix a mistake in the previous commit tick the "Amend Last Commit" and leave the message at the default, this will squash the two commits into one and "hide" the mistake!
+'''NOTE: If the change that's being committed is to fix a mistake in the previous commit tick the "Amend Last Commit" and leave the message at the default, this will squash the two commits into one and "hide" the mistake!'''
 Once committed the main window will show an updated status that lists the commit hash and log message.

@@ Line 72: / Line 72: @@
 '''Note: All features and bugs must be registered with mantis, the ID number that mantis generates for this is the issue id. This id will then be used in naming your branch in the following manner: issueMANTIS_ID (eg., issue0000001)'''
 This puts the current working directory in the new branch ready for the necessary changes to address the bug at hand. The image below shows the state of Git GUI after making the branch, note that just under the menu the current branch is listed and the status bar at the bottom displays the output of the most recent action.
@@ Line 100: / Line 102: @@
 By default the current branch should be selected, if not select the current branch and make sure the Remote Destination Repository is set to '''origin''' and that all options in the Transfer Options are unchecked, then hit the Push button. That's it, now the fix is ready for review! Update the related mantis ticket and head to the IRC channel to find a core developer to assist with the Peer Review.
 == Use Case: Peer Reviewing a Bug Fix ==

@@ Line 106: / Line 106: @@
 Core developers are responsible for spending a portion of their time reviewing others code and making themselves available for peer review, this helps to improve the overall quality of code going into the project by forcing developers to think critically about their own work as well as that of others. In this example a bug that was fixed in the previous use case has been updated on the mantis tracker that it's ready for review. To begin reviewing a branch of code perform a pull to make sure you have the latest changes by going to '''Remote -> Fetch From -> origin'''. Then create a local tracking branch to review the change by going to Branch -> Create..., the image below shows the options necessary to checkout the fix for issue 0000001.
--- IMAGE PLACEHOLDER --
+[[Image:DevProcessReview1.png]]
 Once on the correct branch it's time to review the changes. Git GUI makes this a snap with the '''Repository -> Visualize issue0000001's History''' command which brings up the window shown below.
--- IMAGE PLACEHOLDER
+[[Image:DevProcessReview2.png]]
 The window above provides all the tools necessary to view every change made in the entire history of this line of development! In this example though, only the most recent change is being reviewed and it is selected by default. The bottom left of this screen shows the diff of the changes, a visual depiction of all the changes made in a commit. Each change listed in a diff starts with a tag wrapped in @@ that lists the lines affected by a particular change in the content of a file. Beside each of the lines is either a space, a minus sign or a plus sign. A space beside a line indicates no change while a minus sign indicates a line that has been deleted or modified. Note that lines with a minus sign show the state of the line before a change was made. Plus signs indicate added lines or the new content of changed lines.
 In the above diff we note a slight error in the last commit that the original developer overlooked, the log statement has used a %d placeholder used for printing out numbers while a string was passed as an argument. This highlights the point of performing peer reviews, to help in catching mistakes before they ever make it to the main testing branch. Now the reviewer can point out this issue to the original developer who can then implement the necessary fix. Once that's done the issue can be considered to have passed review and the mantis ticket can be updated to state that the fix is ready to be merged into the main testing branch.

@@ Line 63: / Line 63: @@
-== Use Case: Fixing a bug from mantis ==
+== Use Case: Fixing a Bug From Mantis ==
 Now that a bit of the basics have been covered lets look at a real world example of how this developer workflow works. To do that we'll take a look at one of the more common tasks around here, fixing a bug listed in mantis.
@@ Line 100: / Line 100: @@
 By default the current branch should be selected, if not select the current branch and make sure the Remote Destination Repository is set to '''origin''' and that all options in the Transfer Options are unchecked, then hit the Push button. That's it, now the fix is ready for review! Update the related mantis ticket and head to the IRC channel to find a core developer to assist with the Peer Review.