CORRECTION:
those git-flow commands are:
git flow CMD start TAG
git flow CMD finish TAG
where CMD = { feature, hotfix, release }, etc...
I apologize for the sloppiness - it's past 1AM here.
BTW, git-flow is client-side software - it's not needed on the server
side (git doesn't know git-flow is running).
All it does is make branching and tagging more standard and easier...
- Ken
On Sun, Nov 18, 2012 at 1:00 AM, Ken Feng <[email protected]> wrote:
> Mateusz,
>
> The link you referred to is actually based on a piece of software that
> sits on top of git called git-flow (installable on debian systems via
> sudo apt-get install git-flow).
>
> I have been using it for about six months now (takes a few weeks to
> get used to). I find it absolutely indispensable in my own projects
> now. This is what I typically do:
>
> 1. Before making any changes to the code base, I issue a Bug or
> Feature into redmine so I get a number back.
> 2. Most of the time, it's a feature, so I run git flow feature start
> feature_XXX where XXX is the number in 1.
> 3. git-flow will create a temporary feature branch off of the develop
> branch for me.
> 4. I commit all the code that I code I need to, to feel safe about not
> losing any work.
> 5. When I'm done, I do a git flow feature finish feature_XXX
> 6. git push will push the code back to the server
>
> Sometimes, I need to do a bugfix that needs to go into the master
> branch and the develop branch.
> 7. Like features, I do a git flow feature start hotfix YYY, where YYY
> is some version number - we need a standard version number here
> because the code will end up in develop and in master and anything
> that goes into master should have some kind of standard tagging.
> 8. Finish up with git flow feature finish hotfix YYY
>
> Once in a long while, we need a real release. In that case, we go for
> 9. git flow start release ZZZ
> 10. git flow finish release ZZZ
> where ZZZ is some standard version number again. In between 9. and
> 10., there is usually some QA action along with good
> unit-testing/validation.
>
> I didn't mean for this message to be so long, but I wholly recommend
> the use of git-flow: it really makes good use of git branching under
> the covers.
>
> BTW, for users of git-flow, and in fact, for users of git, it is
> customary/the convention to push to develop and not to master (at
> least not directly), but I don't think there's anything to prevent
> someone from NOT following this convention.
>
> - Ken
>
> On Fri, Nov 16, 2012 at 9:56 PM, Mateusz Loskot <[email protected]> wrote:
>> On 16 November 2012 13:25, Vadim Zeitlin <[email protected]> wrote:
>>> On Fri, 16 Nov 2012 12:57:23 +0000 Mateusz Loskot <[email protected]>
>>> wrote:
>>>
>>> ML> I'm thinking about structuring SOCI development and following
>>> ML> some well-known GitHub practices regarding branching, tagging, etc.
>>> ML>
>>> ML> I've proposed some ideas as a task here:
>>> ML>
>>> ML> https://github.com/SOCI/soci/issues/18
>>> ML>
>>> ML> I'd like to ask everyone for comments,especially related to the model
>>> ML> outlined in the article linked in the ticket.
>>>
>>> Hello,
>>>
>>> This is not a bad model but I wonder if people are not going to be
>>> confused by the need to make patches to (or make pull requests for) the
>>> "development" branch instead of the usual "master".
>>
>> I do have exactly the same concern.
>> I'm not used to the use of "develop" or "next" branch,
>> but I have seen projects using it (e.g. CMake, i3wm.org).
>> I simply integrate my private branches with master directly.
>>
>>> As it seems that many
>>> (most?) changes to SOCI come from people not working on it all the time,
>>
>> Yes.
>>
>> My aim is to favor some sort of open development with anyone
>> encouraged to share her/his ideas, and step forward to take some action.
>> In an ideal world, I'd be happy to grant anyone with write access to Git
>> repo,
>> anyone who would ask for that, but...
>> And here GitHub plays great as it enables folks to contribute easily.
>> It's just that there is someone needed for some kind of traffic control :)
>>
>> We have the SOCI core team, if you will, and that's fantastic.
>> But, I don't expect SOCI members to be contribute on daily/weekly/any
>> frequent basis, so neither of us should feel obliged to be active.
>> (I do not work on SOCI all the time myself either.)
>> The point is, it's just great thing if we push the project forward from
>> time to time, taking tiny steps, even once a year :)
>>
>>> I think that many of them might not suspect that they need to start from
>>> that
>>> branch instead of "master".
>>
>> Yes, good point.
>>
>>> So perhaps this model can be used but with "master" used for development
>>> and some branch with a different name ("stable"? "release"?) for the
>>> releases?
>>
>> Yes, that would simplify the workflow too.
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> soci-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/soci-users
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
