On Sat, Jun 30, 2012 at 1:36 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Thu, Jun 28, 2012 at 7:20 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Hey guys,
>>
>> I put together a first draft of a doc targeted at geotools committers.
>>
>>
>> https://github.com/jdeolive/geotools/blob/gitdoc/docs/developer/procedures/git.rst
>>
>> Highlights of the doc:
>>
>> * Describes how we structure and manage our repositories, canonical,
>> developer forks, etc...
>> * Provides a list of important do's and dont's
>> * Provides other recommendations and good practices
>> * Provides a basic primer that goes over some of the simple workflows
>>
>> All of this I just threw together from my experience on other git
>> projects, i am certainly open to changing anything that is there.
>>
>
> Read it, looks good but I do have questions about pushing.
> Say I work off my fork, and then push to canonical... I guess I will have
> to push to
> my fork as well?
> That is, how is one's fork kept in synch with the canonical one, I guess
> it's not
> something automatic?
>
> Sorry for the silly question, mostly used to work on git against the
> canonical only,
> and with svn basically doing the same (minus a lot of local branches)
>
Not at all, good question. But basically yes, you will have to push to both
remote repositories if you want to keep them up to date. The way i work is
generally when working on the primary branches i don't keep my fork up to
date (on the primary branches) and use it mainly for feature branches. The
idea being that i don;t really see a need for there to be commits in just
my fork on the primary branches, if they can't be pushed up into canonical
directly they should live on a feature branch.
Of course this could change if we start to use pull requests in which i
will need to push a change up to my forks primary branch, issue the pull
request, and have a committer merge it into the primary branch on
canonical. Even then I think when merging a pull request you are free to
choose the target branch for it.
So my workflow on the primary branches is:
git checkout master
# do my work, fix a minor bug, etc..
git add
git commit
git pull --rebase geotools master
git push geotools master
So essentially always just always updating my local repo from canonical. If
i want to resync a primary branch on my remote fork:
git pull geotools master
git push jdeolive master
For feature branches instead I always push to my repo up unti i am ready to
merge it into one of the primary branches.
git checkout -b feature master
# do some work
git add/commit
git push jdeolive feature
# time passes, more work, ready to merge
git checkout master
git pull geotools master
git merge my_feature
git pull --rebase geotools master
git push geotools master
Hope that all makes sense. Clear as mud? :)
> Cheers
> Andrea
>
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
