You just got me convinced to go with Thierry's tooling... Phil Le 28 juin 2014 17:13, "Johan Brichau" <[email protected]> a écrit :
> 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 > > > > > > >
