I appreciate your reply, and apologize for taking too long to respond.

Thank you for your concise explanation as well as connecting me to the 
Yeoman channel - it would certainly come in handy in the future.

Regarding your view about alternative solutions, I completely agree with 
all of your points. I eventually opted to use 
git-directory-deploy<https://github.com/X1011/git-directory-deploy>with Yeoman 
- it simplifies the whole deployment/publishing process, and it 
is CI ready, so as our project expands we'll be already covered from that 
angle too. It was also very easy to set up.


On Tuesday, October 22, 2013 11:24:32 AM UTC+3, Thomas Ferris Nicolaisen 
> On Saturday, October 12, 2013 11:21:47 AM UTC+2, Tom Alon wrote:
>> I use one repo with develop and release branches for a Yeoman project.
>> Simplified, my directory tree looks like this:
>> root git directory
>> ├── app 
>> └── dist (the build folder)
>> With Grunt.js I build my app straight into dist. 
>> I would like to use git subtree push --prefix dist origin release to 
>> conveniently update release with a new build - as detailed in the Yeoman 
>> documentation <http://yeoman.io/deployment.html>.
>> Do I need to track, commit and push the dist directory in the developbranch 
>> at all times to use this method?
> Well, you have to commit it in order to do the subtree push, so it's 
> already being tracked. 
>> I would like to know as well - since on my own, I could not make the 
>> above work conveniently - would a submodule tracking the release branch 
>> be a better solution?
> It's hard to say what would be "better", as it's a subjective thing. 
> Perhaps you would be better off discussing this with Yeoman users? They 
> have an IRC channel #yeoman on FreeNode.
> Personally I find it somewhat of an anti-pattern to check in built 
> artifacts, but for small projects it doesn't matter in the short run. 
> Putting the dist stuff in a submodule would probably be better long term, 
> but it adds complexity, and that's probably why the Yeoman guide doesn't do 
> that. 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to