Hey everyone who's collaborating, I started using git-flow tonight, and it's working pretty well, so in the interest of everyone keeping sane, please install it and start using it as they describe in: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ And also as shown in: https://github.com/nvie/gitflow Here's the quick instructions: 1. Install git-flow as in the README on github. 2. In the mongrel2 run: git flow init 3. Just hit enter for all the defaults. Don't get fancy. 4. Start your hacking using: git flow feature start BlahBlahBlah 5. commit like normal, don't push or tag anything. 6. End this feature with: git flow feature finish BlahBlahBlah 7. git push origin develop That's pretty much it. There's not a develop branch on github where all the real hacking goes, and I'll be trying to use this to put out a 1.7 release sometime tomorrow. For those who aren't a collaborator you probably just want to track the developer or master branch depending on what you want. -- Zed A. Shaw http://zedshaw.com/
2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: > Here's the quick instructions: > > > 1. Install git-flow as in the README on github. > 2. In the mongrel2 run: git flow init > 3. Just hit enter for all the defaults. Don't get fancy. > 4. Start your hacking using: git flow feature start BlahBlahBlah > 5. commit like normal, don't push or tag anything. Actually, there is no problem if someone needs to publish a feature branch to get some code-review before merging it back do develop branch, right? Or the better is to always push the code to the develop branch and if it needs a code review or any modifications we should commit directly on develop? I think both a valid workflows. -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com
On 2011-06-04 15:20, Dalton Barreto wrote: > 2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: >> Here's the quick instructions: >> >> >> 1. Install git-flow as in the README on github. >> 2. In the mongrel2 run: git flow init >> 3. Just hit enter for all the defaults. Don't get fancy. >> 4. Start your hacking using: git flow feature start BlahBlahBlah >> 5. commit like normal, don't push or tag anything. > > Actually, there is no problem if someone needs to publish a feature > branch to get some code-review before merging it back do develop > branch, right? > > Or the better is to always push the code to the develop branch and if > it needs a code review or any modifications we should commit directly > on develop? > > I think both a valid workflows. Never forget the purpose of git flow. The purpose is only to force you to work on a feature branch on your local dev setup and merge it back into develop in a non fast forwarding way to keep the history of the commits of your feature branch in the main repo. The standard fast-forward is making a one line flat history. The git flow --no-ff way will keep the branch info. This is really nothing more. We are 5 regular coders on Indefero and we use the git flow approach with and without git flow. This works perfectly well. loïc
On Sat, Jun 04, 2011 at 10:20:30AM -0300, Dalton Barreto wrote: > 2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: > > Here's the quick instructions: > > > > > > 1. Install git-flow as in the README on github. > > 2. In the mongrel2 run: git flow init > > 3. Just hit enter for all the defaults. Don't get fancy. > > 4. Start your hacking using: git flow feature start BlahBlahBlah > > 5. commit like normal, don't push or tag anything. > > Actually, there is no problem if someone needs to publish a feature > branch to get some code-review before merging it back do develop > branch, right? I'd rather not unless it's a big feature, otherwise we'll have tons of pointless feature branches poluting the list on github. > Or the better is to always push the code to the develop branch and if > it needs a code review or any modifications we should commit directly > on develop? That's what I'd go for since there's no bets on develop being stable, but I think the better advice is, "Talk on the mailing list before trying to start a featuer if you have no clue and need help." That's better than using github as a kind of mailing list to ask if you're doing it right. -- Zed A. Shaw http://zedshaw.com/
2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: > On Sat, Jun 04, 2011 at 10:20:30AM -0300, Dalton Barreto wrote: >> 2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: >> > Here's the quick instructions: >> > >> > >> > 1. Install git-flow as in the README on github. >> > 2. In the mongrel2 run: git flow init >> > 3. Just hit enter for all the defaults. Don't get fancy. >> > 4. Start your hacking using: git flow feature start BlahBlahBlah >> > 5. commit like normal, don't push or tag anything. >> >> Actually, there is no problem if someone needs to publish a feature >> branch to get some code-review before merging it back do develop >> branch, right? > > I'd rather not unless it's a big feature, otherwise we'll have tons of > pointless feature branches poluting the list on github. > >> Or the better is to always push the code to the develop branch and if >> it needs a code review or any modifications we should commit directly >> on develop? > > That's what I'd go for since there's no bets on develop being stable, > but I think the better advice is, "Talk on the mailing list before > trying to start a featuer if you have no clue and need help." That's > better than using github as a kind of mailing list to ask if you're > doing it right. > Awesome! Thank you very much! I will try to grab some thing to do. Thinking about the 100-Continue support. Seems to be a small implementation and will make me more confident. -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com
2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: > Hey everyone who's collaborating, > > I started using git-flow tonight, and it's working pretty well, so in > the interest of everyone keeping sane, please install it and start using > it as they describe in: > > http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ > > And also as shown in: > > https://github.com/nvie/gitflow > > Here's the quick instructions: > > > 1. Install git-flow as in the README on github. > 2. In the mongrel2 run: git flow init > 3. Just hit enter for all the defaults. Don't get fancy. > 4. Start your hacking using: git flow feature start BlahBlahBlah > 5. commit like normal, don't push or tag anything. > 6. End this feature with: git flow feature finish BlahBlahBlah > 7. git push origin develop > Done. Maybe it would be a good idea to instruct everyone to run the setupgit.sh script before start hacking the code. Just added gitflow to the setupgit.sh. > That's pretty much it. There's not a develop branch on github where all > the real hacking goes, and I'll be trying to use this to put out a 1.7 > release sometime tomorrow. > Is the loadable filter feature planned only for 1.8? 1.7 you just have the internal infrastructure for loading them, right? Note: For some reason, cloning a fresh new mongrel2 repo does not bring the develop branch. I had to "git flow init" the repo and then "git pull origin develop" so I could commit the setupgit.sh modification. Thanks. -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com
On Sat, Jun 04, 2011 at 10:12:36AM -0300, Dalton Barreto wrote: > Done. Maybe it would be a good idea to instruct everyone > to run the setupgit.sh script before start hacking the code. > > Just added gitflow to the setupgit.sh. Awesome, good call. I'll beef up the instructions shortly. > Is the loadable filter feature planned only for 1.8? 1.7 you just have > the internal infrastructure for loading them, right? I'm going to thrash the config setup some more, and then I'm going to improve the config of SSL to make sure that making new configs is easier. Once I got that, I can do the configs for modules and get them working. > Note: For some reason, cloning a fresh new mongrel2 repo does not > bring the develop branch. I had to "git flow init" the repo and then > "git pull origin develop" so I could commit > the setupgit.sh modification. Ok, that's fine since it's really just for us right now, but I'll look at improving the instructions. -- Zed A. Shaw http://zedshaw.com/
2011/6/4 Zed A. Shaw <zedshaw@zedshaw.com>: > On Sat, Jun 04, 2011 at 10:12:36AM -0300, Dalton Barreto wrote: >> Note: For some reason, cloning a fresh new mongrel2 repo does not >> bring the develop branch. I had to "git flow init" the repo and then >> "git pull origin develop" so I could commit >> the setupgit.sh modification. > > Ok, that's fine since it's really just for us right now, but I'll look > at improving the instructions. > So I faced this same problem with one of my projects that also uses git-flow and I realized that the github repo was not set to use the develop branch as the "default branch". So just go to the Admin page of the mongrel2 repo and set "develop" as the defualt branch, this should fix the problem and anyone wanting to hack the code will be able to do it with a simple git clone, since this will bring the develop branch. -- Dalton Barreto http://daltonmatos.wordpress.com http://wsgid.com