Earlier quoted context omitted.
I develop in master sometimes, but only check in small edits that are pushed immediately. If my edits grow to the point that I need to write tests or push to staging, I just checkout a feature branch before committing.
If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.
Why aren't you using git-flow?
21–30 of 55 posts
Re: Why aren't you using git-flow?
#22We don't use git-flow because we don't have any problems managing our code.
Re: Why aren't you using git-flow?
#23Has anyone used git-flow with an existing repo? It seems like existing branches could just be renamed from "myfeature" to "feature/myfeature", etc. but I wonder if others have been down this road and have run into issues.
Here's a gist I created showing how an existing repo (although very basic) can be adapted to use git-flow - http://gist.github.com/538326
Re: Why aren't you using git-flow?
#24Re: Why aren't you using git-flow?
#25Earlier quoted context omitted.
If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.
It sounds like git-flow removes some hassle, can anyone answer the question about adding git-flow to an existing repo?
Re: Why aren't you using git-flow?
#26Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining. Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense. EDIT: Please not I am not suggesting that you not do fea…
If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master. If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new b…
If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.
I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.
(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)
Re: Why aren't you using git-flow?
#27I don't know that this could be added to it and not make it entirely more complicated.
Re: Why aren't you using git-flow?
#28I typically don't like tools like this. They hide too much of what is going on.
Re: Why aren't you using git-flow?
#29Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining. Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense. EDIT: Please not I am not suggesting that you not do fea…
Master exists as a pristine releasable code base. Develop is the main branch for working on things, and branching usually happens from there. Having master and develop lets you keep developing on your project while having a frozen deployable branch master in this case.