Stef, all, First, you need to know how to work with git and understand the vocabulary. Otherwise, you _will_ get confused, and probably get disgusted. So, beware... git was made for and by linux people, which is all I am going to say about that...
In my experience, tools always help and I can recommend sourcetree [1] or git tower [2]. Reading the links that Dale mentioned is a very good idea too. Next, Dale's 'getting started with github' [3] is a good intro to make your first git project work and understand the extra steps you need to make to manage source code. It does not have to be a github project. Let me also comment a bit on why we (at Yesplan) are now trying to switch from monticello to git for our daily work. I am using git for over a year now and we are actively switching to use it on a daily basis. First of all, in our daily work, we need continuous deployment. When a feature is ready, it must be shipped into production as soon as possible. If you are not the only one working on a codebase, continuous deployment requires that each feature is developed in its own branch and can only be integrated with the main codebase when it's ready and stable. Monticello just does not support branching well. In Git, this is natural. You can easily create feature branches, do partial publishes, merge the changes from the main codebase back into your feature branch, explore the version history, etc. I must also add that github's pull request and code commenting feature is a very productive way of working together on the same codebase in a structured way. About a year ago, I almost only used git tools to merge in the changes from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a huge amount of package changes, which is about the worst case scenario to understand any evolution and merge it in a port (which has code changes itself). In about an afternoon of work, most of the dust had settled and I was using the git merge to understand code moves and to prevent gemstone-specific changes from being overwritten again. The best part there was probably the sub-method-level merges. Also, the reason I did not need any Smalltalk browser to do the merges is because filetree exports packages and classes as directories and methods as files. If you use the column layout of the Finder on Mac, the Finder becomes the System Browser (at least for understanding and navigating the structure of the source code, which is what you need at that level). Sourcetree had such a browser internally until very recently... so I am disappointed they removed that. Besides numerous other projects, we have Seaside hosted in a github repository too. The advantages are that we can test every feature branch and every platform automatically with Travis CI. We don't use pull requests in the community, but if we did, it would be way easier for contributors and maintainers. Forking and pulling makes it easy for people to patch something and contribute the code back, while at the same time, it allows the maintainers to protect the code base from harmful changes. Finally, the biggest pain with filetree is that it carries the monticello metadata. If you work together on the same branch, you _will_ get stupid merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge tool [5] is a wonderful tool. Since I started using that, merges of the metadata are done by git automatically and I just forget about them. Nice work Thierry! Another pain is that publishing and loading code is a two-step process: files on disk and code in your image. You need to very carefully synchronize these. You may switch a branch on disk but forget to load it in the image, or start publishing code from the image to the disk where a different branch was checked out. This is where better tools for git from within the image will help. those were my 2 cents ;-) Johan [1] http://www.sourcetreeapp.com [2] http://www.git-tower.com [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStartedWithGitHub.md [4] https://github.com/glassdb/Seaside31 [5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver On 28 Jun 2014, at 10:12, stepharo <[email protected]> wrote: > thanks > > Now is there a tutorial? Beause > http://forum.world.st/Pharo-git-td4693999.html scared me. > > > On 27/6/14 15:53, Goubier Thierry wrote: >> >> >> Le 26/06/2014 19:11, Yuriy Tymchuk a écrit : >>> I can only suggest you to read my blogpost about configurations and >>> versioning: >>> http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html >>> >>> I usually mix filetree and gitfiletree. Last one is better, because you >>> don’t have to remember to commit in git each time you commit in pharo. >>> (Also I think that gitfiletree is not working with Pharo4) >> >> Now it works with Pharo4! >> >> Thierry > >
