Using GIT for Dataflex Development: Difference between revisions
Using GIT for Dataflex Development (view source)
Revision as of 09:16, 6 November 2012
, 6 November 2012→Using GIT during developing & a centralised VCS for releases
| Line 330: | Line 330: | ||
= Using GIT during developing & a centralised VCS for releases = | = Using GIT during developing & a centralised VCS for releases = | ||
You might find yourself in an environment where the boss insists on using a centralised version control like VSS or Vault for the releases, but you are keen on using GIT with its awesome branch feature. | |||
You would join a great deal of young developers that during their study the last years developed open source software and are very aware of the advantages of GIT. They new find themselves in this situation where they feel they have to do a step backwards. | |||
I think, and many online agree that the two VCS’s are not mutually exclusive. You can use GIT during the development, smoke testing or even proper testing and get all the advantages of the development freedom. When it is time for releasing, just check the code into your centralised VCS. | |||
= Multiple developers, multiple repositories = | |||
In previous section you got familiar with staging, committing, branching and merging. All of these actions were done on the local repository. | |||
More than likely you are working in a team of developers or at least want a safe backup of the repository. In both cases you want to synchronise your local repository with one or more remote repositories. | |||
== Create a remote backup repository == | |||
To make a backup of your repository you can either use a hosted solution or just on another piece of hardware in the network. The follow the following steps show the latter. | |||
In Git Gui choose menu Remote – Add. Give the backup location a name and the path. Although not mandatory, its common to give the foldername a .git extention. | |||
[[File:UsingGitforVdfDev image021.png]] | |||
Make sure you change the ‘Further Action’ from ‘Fetch Immediately’ to ‘Initialize Remote Repository and Push’, and click Add. | |||
'''If you are putting a network drive as the location, make sure you use ‘//drive/dir/dir’ instead of ‘\\drive\dir\dir’. Otherwise you will have issues later on.''' | |||
What just happened in simplified terms, is that important content of the workspace .git folder is copied and links are setup between the local and the remote repository. This remote repository is often called a ‘bare repository’ is it does not have a working directory. | |||
After you make changes to your local repository, and you would like to update the remote repository, all you have to do is a Push. Menu: Remote – Push or (Ctrl+P); | |||
[[File:UsingGitforVdfDev image022.png]] | |||
By default the current branch is selected as Source Branch, but you could like above select multiple (Shift or Ctrl left click) branches to be updated. | |||
Please note that you are pushing the whole history of commits, not just the latest state. | |||
== Creating a local repository from a remote repository == | |||
So your mate has started to use Git in his local repository, and made a backup remote repository on the server. You have to also do some work on this project so you need a local repository. | |||
In Git terminology you want to clone an existing repository. | |||
''To practice this there is no reason that this would not be on the same machine (just different directory). Even the remote backup created could have been on the same local machine in its own directory.'' | |||
Start Git Gui from start menu or by right mouse click on any directory that does not have a repository. | |||
[[File:UsingGitforVdfDev image023.png]] | |||
Click the Clone existing repository link. | |||
[[File:UsingGitforVdfDev image024.png]] | |||
Enter the location of the Remote repository and the NOT YET CREATED target local repository and workspace. | |||
Select the Full Copy, just to be sure. When you’ve worked with Git for a while feel free to experiment with the faster versions, but in the beginning you just want it to work. | |||
When clicked clone, navigate your explorer to the new directory and confirm that you have the full workspace, as well as a .git local repository. You also will find the remote automatically added to the ‘Remote’ menu as ‘origin’. | |||
''If you added the .gitignore file to not be tracked (my mentioning it in the .gitignore file itself) it was not copied over into the cloned workspace. You probably want to copy this file manually here. It is recommended though that you do stage and commit this file into your repository.'' | |||
== Keeping multiple repositories synchronised == | |||
In previous sections you have created a new remote repository with ‘Add remote’, and created new local repository by cloning the repository from the remote. | |||
We also discussed that a remote repository can be kept up-to-date with Push. | |||
Suppose developer 1 makes a change to a file eg the remaining WinPrint report fonts are all changed from Arial to Segoe ui. The developer stages the files, and does a commit, this saves the changes into the local repository. He then at the end of the day does a push, to update the remote repository with these changes. | |||
For developer 2 to retrieve these changes, two actions need to be undertaken. First the local repository needs to be updated using the menu option Remote – Fetch. Then the workspace (working tree in GIT language) needs to be updated with changes from the repository. This done by menu option Merge – Local Merge (or Ctrl+M), leaving the defaults in the merge dialog as Tracking branch. | |||
When an automated 3 way merge can be done, this is very simple. When however conflicts occur they are shown to the user, than then can do a proper merge. Once developer 2 is finished merging the developer 1’s changes into their code he makes sure all is committed, then pushes the changes to the remote repository. | |||
This sounds more complex than it is. Git also helps you with this. Basically git’s remote repositories do not allow a push, if there are un-fetched (pulled) changes. Therefore the developer would always be prompted to pull, merge, commit and then push. | |||
== Local and Remote branches == | |||
Local branches are not automatically pushed to the remotes. This leaves you with the freedom to use private branches for work you do not want to share. | |||
If you do want to collaborate on a branch, you explicitly push the branch to the remote. | |||
When a branch is pushed to the remote and other developers do a Fetch, they will automatically receive a reference to new remote branches, but you don’t automatically get editable copies of them (only a ‘origin/<branch>’. So if they want to contribute to the branch, they need to create a Tracking branch based on the remote branch. | |||
The tracking branch is to the developer like a local branch, except GIT knows the link to the remote branch, so a push will automatically update the correct remote branch. | |||
In Git GUI and specifically the dialog below the wording of the labels is confusing. Where it reads ‘Tracking branch’ it should be ‘Remote branch’. After all a tracking branch is the result of the action, not the source | |||
[[File:UsingGitforVdfDev image025.png]] | |||
So this creates a Tracking branch ‘CR5612_UpdateFontsOnReports’ (due to the ‘Match Tracking branch name’ setting), linked to the remote branch ‘origin/ CR5612_UpdateFontsOnReports’. | |||
So a Tracking branch is a local branch that has a direct relationship to a remote branch. If you are on a tracking branch and do a push, GIT knows what remote and branch to push to. If you do a pull, It fetches all the remote branches and automatically merges in the changes from the remote branch. | |||
== Collaborating on a topic branches == | |||
Some great text on [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project] | |||