2

I'm a Git beginner. I'm reading and trying out this Git tutorial. And I have also read the Git branching model here and this question on SO.

But I'm still confusing how I should use Git properly for my case below:

  1. I have a project MyProject01. I will be working on it from a PC, says PC01
  2. Another developer sitting on another PC, says PC02, will clone the project MyProject01 (git clone, git pull, etc.) and then will be working on it.
  3. Then, those two will be synchronized (probably git push to PC01, but I'm not sure of that). For example, I'm working on file.prg on PC1 to write function 1 while another developer is working on the same file file.prg on PC2 to write function 2. Those will be merged to get the final outcome - file.prg with function 1 and function 2 done.

I'm not using Git as full version control, i.e., the version will be controlled by myself such as MyProject01, MyProject02, etc. Git will be using (git init) for each individual directory. I just want to use Git as multi-developer environment for my Visual FoxPro desktop application development.

According to my case, do I need to create a bare repository cloned from repo01 as described in the tutorial; repo01 would be MyProject01?

I think I'm not suitable with the branching model described above. Please guide me to the right way.
I'm using the Git installer for Windows.

[Edit]
My primary goal is to use Git as Source Control similar to:

Community
  • 1
  • 1
Sithu
  • 4,752
  • 9
  • 64
  • 110
  • After reading the PDF [VFP Version Control with Mercurial](http://www.ita-software.com/papers/Borup_Mercurial_Published.pdf), I decided to use [Mercurial and TortoiseHg](http://tortoisehg.bitbucket.org) because (1) the documentation which meets my requirement of VFP 99% (2) well integration with the Windows shell (3) good and user-friendly GUI tool. The question was originally for Git, but I did not find any step-by-step guide of Git to use with VFP. And I found [a question and answers](http://stackoverflow.com/q/35837/1179841) that are very helpful for me to choose Mercurial over Git. – Sithu Apr 08 '15 at 03:20

4 Answers4

6

I know this is a 10 months question, but surely this could be useful anyway.

From january 2014 there is a new replacement for scctext(x).prg called FoxBin2Prg, which can convert VFP 9 binaries to text (prg style ones) and can regenerate the binaries from this texts. Can be used to Diff and Merge code and the generated text can be modified, and the changes reflected on the regenerated binaries.

It is hosted on VFPx Project, at this url: https://github.com/fdbozzo/foxbin2prg

Actually I'm using it integrated with PlasticSCM in a 10 members team without the need of blocking files, using concurrent development even on the same forms and classes.

Best regards!

Fer B.
  • 425
  • 5
  • 11
2

I'm not using Git as full version control, i.e., the version will be controlled by myself such as MyProject01, MyProject02, etc. Git will be using (git init) for each individual directory

Why bother with git then, if you're just going to throw away old histories?

If you don't want histories, then diff and patch will serve you just as well. In git, in addition to having multiple branches in a single repository, you can also create multiple working copies by cloning the repository. Having multiple branches allow you to preserve histories from previous versions while also allowing you to go back to a previous version and make modifications; having multiple working copies allows you to run multiple versions of the program simultaneously or store files that were not checked in but is version specific (e.g. sqlite database file). There is no reason to reset revision history every time you create a new version.

(probably git push to PC01, but I'm not sure of that)

Yes, you can do that because in a DVCS you can push or pull from any repository to any repository (this is what differentiates distributed VCS from centralized VCS, the other main difference is that in DVCS a working copy is always also a repository with full history instead of just a snapshot of a specific revision). With that said, setting up a bare repository is still a good idea to make code sharing easier. If PC02 need to push but PC01 isn't online, then PC02 would have to wait until PC01 is online to be able to push, a bare repository on a server that is always online wouldn't have that problem.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
  • Thank you for your answer. I'm not going to throw away old histories. Currently, I do it manually, i.e., after I have released 1.0 and I'm going to work on 2.0, I clone the folder `MyProject-1.0` and name it into `MyProject-2.0`. Same for every single file in the project folder. So, I have every old history. I just want to use Git for synchronizing and merging among copies. I'll keep my self-control version style. May be I use Git version (tag) for individual files in the project folder. Am I on the right track using Git for that purpose? – Sithu Aug 14 '13 at 08:19
  • `Same for every single file in the project folder` <- what do you meant by that? As to your other question, you can certainly use git just for sync and merge, git itself doesn't endorse nor prohibit any specific workflow; but you're missing an awful lot of power for no obvious reason. – Lie Ryan Aug 14 '13 at 08:25
  • `Same for every single file in the project folder` <- I mean that I have `utility-1.0.prg` in my project folder and when I want to make an update in that file, I copy the file and rename it to `utility-2.0.prg`. I'm using this way since last 6 years. So, it is difficult for me to move completely into the Git awful should-be workflow for all of my existing projects. – Sithu Aug 14 '13 at 08:37
  • As my team is sitting and working in an office, we can work simultaneously on the server for a web project, except that we cannot edit the same file at the same time. So we don't need such `git pull/push/clone` in our web development. But for desktop development, I need this `clone/pull/push` to have each copy for each developer since the same project cannot be opened simultaneously. – Sithu Aug 14 '13 at 08:50
  • @Sithu: yes, that's what I feared. You lose the benefit of keeping history that way. You can't git bisect, can't git blame, can't get a git diff across versions, can't git cherry pick, you don't have a proper way to fix issues on an old version. Your workflow, while doable in git, is no better off than just using patch and diff. You're doing things the hard way. Some things need to change and sometimes that thing is you. – Lie Ryan Aug 14 '13 at 09:15
  • @Sithu: You don't know what you're missing. Those are powerful tools that doesn't work as well with the way you're doing things right now. git bisect, for instance, are used if you have a bug in the latest version 4.0 but you know that the bug didn't occur way back in version 1.0 and you want to quickly find the changeset that introduces the regression so you know what to fix. With the way you do things now, doing that become a lot manual. You also can't undo a commit on an old version using revert, and instead have to make changes manually. You also can't use cherry-pick to backport fixes. – Lie Ryan Aug 14 '13 at 10:47
2

Check https://github.com/sait/vfpscm

PRG files are just plain text, you can use GIT or Mercurial with them transparently.

You have problem with Visual Forms (scx & sct) and Visual Classes (vcx & vct) because those files are DBF tables with a memo file associated; when you modify a form, it change the whole file.

GIT can handle binary files perfectly, but you would not see the diferences in code, and that whats SCM is for.

We create this program: https://github.com/sait/vfpscm that:

  1. Convert your Forms and Classes to XML so you can push them in repository and when you modify the form, only change a few lines in the XML file.
  2. Reconvert XML files to Forms and Classes, to receive that changes.

So the process of using regular GIT change to this:

  1. Edit Files PRGs
  2. Edit Visual Classes and Forms
  3. Testing
  4. Once your bug is fixed or feature is ready:
  5. Convert classes and forms to XML (running VfpScm)
  6. Add files PRGs and XMLs to your Git (git add)
  7. Commit file (git commit -m "messages")
  8. Push changes to repository (git push -u origin master)

Your team would need to pull these changes and add them to their local copy with:

  1. Pull changes (git pull origin master)
  2. PRG and XML would be overwrited by Git
  3. Rebuild Forms and Classes that has been changed (running VfpScm)

GIT is configure to ignore SCX, SCT, VCX and VCT files using .gitignore and the repository only contains PRG and XMLs files

We have been working with VFPSCM.exe tool since 5 years in large projects with 300 forms and 20 classes, and we have never loose any code, and the must important we have the SCM ready, visualizing only the changes made, and a history of commits, that convert in our logbook of changes.

Ignacio Gutiérrez Torrero
  • 37
  • 3
0

You can use Git for multiple projects. Create two folders for project1 and project2 and keep them separate from each other.

Try to use SmartGit in the start.

Git is not a traditional source control system. It is distributed source control system. I would still suggest you to start with a GitUI in the beginning.

Yes you should have a bare repository.

user2483744
  • 283
  • 1
  • 5
  • 11
  • 1
    Thank you for your suggestion of SmartGit. I'm still OK with Git Bash. – Sithu Aug 14 '13 at 08:40
  • 2
    I strongly recommend ***against*** using a GUI with Git, even for beginners, because they abstract away too much knowledge about how Git actually works. If ***anyone***, including beginners, wants to learn and become proficient in Git, then they ***must learn to use it from the command line***. –  Aug 14 '13 at 12:16