Using GIT for Dataflex Development: Difference between revisions
Using GIT for Dataflex Development (view source)
Revision as of 09:05, 6 November 2012
, 6 November 2012→Creating a branch and making changes
| Line 224: | Line 224: | ||
If you are happy with the changes, then Stage and commit them. | If you are happy with the changes, then Stage and commit them. | ||
== Merge branches == | |||
The previous section might unsettle you a bit. We made two changes, both from the same base code (master) but now we want to compile them both into one test version to give to the testers. | |||
We do this by merging. We first create a new branch called ‘Version2.0Beta1’, with starting revision ‘master’. When done we have again the source code the same as the master. | |||
Now we merge the changes in the branch ‘CR5612_UpdateFontsOnReports’ and ‘CR5613_ShowTotalSalesOnSalesPersonDialog’ into this ‘Version2.0Beta1’ branch. Do a local merge via menu open Merge-Local Merge, or Ctrl+M. | |||
[[File:UsingGitforVdfDev_image014.png]] | |||
Select the first branch and click Merge. Then go back to the Merge dialog (Ctrl+M) and select the other one. | |||
Git has a fantastic build in 3 way merge, illustrated in the image on the right. | |||
However you possibly see that that there is a conflict and the Automatic 3way merge failed as a change from the base version was found in both branches on the same line. This raises a merge conflict. The following screens go into solving this; | |||
[[File:UsingGitforVdfDev_image015.png]] | |||
[[File:UsingGitforVdfDev_image016.png]] | |||
Close the dialog informing you of the merge fail and check the presented merge conflict. I’ve drawn two arrows to the important text. | |||
[[File:UsingGitforVdfDev_image017.png]] | |||
The text ‘VersionBuild=1’ is indicated with ‘HEAD’. This is a pointer to the local current branch, and thus indicates the current committed code for the current branch. The ‘VersionBuild=6’ is marked with the branch name ‘CR5613_ShowTotalSalesOnSalesPersonDialog’. | |||
Please note if you compiled both source codes the same number of times or have turned ‘Auto-increment build version’ off in the project properties, you will not have this conflict. Also if you checked in the branch in the other order, you would have the other branch shown here. | |||
In this case the build number is probably not of great concern but, it is great that GIT detected that you have a change in both branches on the same line and just want to show you this so you can make the correct decision regarding fixing this. | |||
In reality the file in your workdirectory is updated with the <<<Head ... >>> Branch text. This file is also shown as unstaged. You have the following options: | |||
# Update the file outside of git-gui (in this stage eg notepad++). Then save the manually merged file, do a Rescan, Stage & Commit | |||
# Run Mergetool (eg. KDiff3) to show the base(closest common parent), the first and already merged branch, and the second branch. You can simply select the change to keep. It will create by default a .orig with the merge conflict | |||
# Use remote version (latest merge) /Local version (previous merge) or Base (closest common parent) | |||
Whatever your choice of addressing the merge conflict, you stage and commit the version to keep. | |||
Now Switch back to the studio, compile the project and confirm that both the sales person amount and the winprint changes are in this ‘Version2.0Beta1’ branch. | |||
The test version is ready for... testing. | |||
''Just remember to merge, switch to (checkout) the branch you want to merge into. Then select the branch that you want to merge into the current branch.'' | |||
== Further changes required on one of the change requests == | |||
As normal the test version comes back with a number of changes that are required. Let’s say that the first one is that the total amount form should not be visible if no record is shown. | |||
It could be tempting to make this change in the ‘Version2.0Beta1’ branch but resist. The changes should be made in the branch linked to the change request. So we need to switch branches. In Git this is called ‘checkout’. This does not have much to do with the function Checkout in centralised version control systems, but you can imagine its function is related. | |||
So via the menu do Branch-Checkout or Ctrl+O. On the Checkout Branch dialog select the CR5613_ShowTotalSalesOnSalesPersonDialog local branch and click Checkout. | |||
[[File:UsingGitforVdfDev_image018.png]] | |||
If you get an error ‘File level merge required’ regarding the Order.cfg, it means that this file is changed on disk from the current committed code in the current branch (still Version2.0Beta1). This would have been as you probably compiled the code after the last merge and still had the Auto increment on. | |||
[[File:UsingGitforVdfDev_image019.png]] | |||
So GIT basically checks if any changes would have been lost by changing to another branch (checkout) while the changes were not yet committed or reset. | |||
So we just click ok on the dialog. We rescan and stage the order.cfg file, but for the commit we do not enter a message, instead we use the radio box and move from ‘New commit’ to ‘Amend last commit’. We then do Commit. | |||
This feature of Amend last commit is very helpful when you just committed something and find that you forgot a feature have a silly bug etc and just don’t want this to be tracked as a separate commit. | |||
Now we can go back to our checkout of the CR5613_ShowTotalSalesOnSalesPersonDialog branch. Use Ctrl+O, select the branch and click checkout. | |||
Confirm that the current branch switched; | |||
[[File:UsingGitforVdfDev_image020.png]] | |||
Switch back to VDF Studio and the SalesP.vw file. Change the Refresh procedure to the following code: | |||
<nowiki> | |||
// This only works from VDF 17.0 where Refresh is also send to containers | |||
Procedure Refresh Integer eMode | |||
Handle hoServer | |||
Boolean bHasRecord | |||
Get Server to hoServer | |||
Get HasRecord of hoServer to bHasRecord | |||
If (bHasRecord) Send CalculateTotalSales to oTotalSalesForm | |||
Set Visible_State of oTotalSalesForm to (bHasRecord) | |||
Forward Send Refresh eMode | |||
End_Procedure | |||
</nowiki> | |||
Compile and confirm the code. | |||
To avoid further issues with the config.cfg we will turn the auto increment off. Although I think there is a lot of value in the build number, I think it should be increased for every version that leaves the developer (test and release versions), not during the actual development. In the VDF Studio do Project – Project Properties, select the Version tab and untick the Auto-Increment build version. Click OK to save the change. | |||
We now want to attend to the other changes to the winprint report. But we have not staged and checked in the new code. If you were to forget the ‘file level merge is required’ would appear again. We don’t want this, so we properly stage and commit the change as a new commit with eg ‘Request 1 from testing beta1, hide total amount form on clear.’ | |||
We change branch by Checkout of the PlayWithWinPrintReports and make out changes there. | |||
When these are all nicely done and committed, we create a new branch‘Version2.0Beta2’, based on master and merge the two branches in. | |||
You could decide to create the new branch based on ‘Version2.0Beta1’. I personally don’t see an advantage of this, but you could. | |||
== Branching – Merging wrap-up == | |||
I think each change request should have its own branch. As you have seen above, it is really easy to create branches, merge the changes and create (test) release branches with the features. This has advantages that features that are not complete at the time of release will simply not be merged into that release. All code changes stay in the branch and will be further worked on when you decide to do so. Working properly with branches means there is a minimal risk of issues and make it much easier to make Agile iteration/sprints where a release is time boxed but the less critical features are not. | |||
You could see the topic branches as only developer help. The commits should have the proper references to the code and properly document the changes. Therefore once the topic branch is merged into the master, the topic branch itself can be deleted, as all the commits are inserted into the master branch. | |||
= Using GIT during developing & a centralised VCS for releases = | |||