Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why aren't you using git-flow?

jeffkreeftmeijer.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Why aren't you using git-flow?

#31

Post by jsarch »

blaix wrote: post #24

I typically don't like tools like this. They hide too much of what is going on.

While I understand your concern, a feature of gitflow IMO is that you can switch between git and gitflow as you wish. Personally, I like the constraints that gitflow creates because it simplifies the process of pushing out releases.

Since time is my number one constraint right now, I'm taking advantage of every tool that makes me more productive. Yes, you can certainly implement the workflow with vanilla "git" but if you're going to follow the workflow model, why not use a tool that excels at that workflow? especially when said tool allows you to see what it's doing.

Re: Why aren't you using git-flow?

#32

Post by mltsy »

kevinold wrote: post #23
kevinold wrote: post #12

Has 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.

I've done some playing around with a dummy "existing" repo and it seems to adapt well. Upon "git flow init" it identifies existing branches and proceeds with the questionnaire in the article above associating. 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

This gist is literally the most helpful thing I have ever read in under 5 minutes :D Especially with all mistakes included and averted. Thank you! :)

Re: Why aren't you using git-flow?

#34

Post by Vitaly »

brown9-2 wrote: post #10
KirinDave wrote: post #9

Git 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…

its actually very easy.

You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into master and delete it:

    git branch hotfix v1.2.3
    git co hotfix
    # do the fix
    git tag v1.2.4
    # deploy
    git co master
    git merge hotfix
    git branch -d hotfix

Re: Why aren't you using git-flow?

#35

Post by swatermasysk »

bobbywilson0 wrote: post #7
rlpb wrote: post #5

I do the same thing without git-flow already. What will git-flow give me that I can't easily do or is awkward with using git directly?

If you are doing this style exactly without git flow, you don't gain a whole lot. It is great if you are working with a team then it forces everyone to work the same way and is very clear what you do in each situation. One of my favorite features of git-flow is housekeeping, for features when you close them it merges to develop and destroys the branch, when you do a hotfix it merges to master and develop and destroys…

I haven't used it yet, but I have to agree that forcing a team through the same general process would be a very big win.

Re: Why aren't you using git-flow?

#36

Post by rlpb »

swatermasysk wrote: post #35
bobbywilson0 wrote: post #7

Earlier quoted context omitted.

If you are doing this style exactly without git flow, you don't gain a whole lot. It is great if you are working with a team then it forces everyone to work the same way and is very clear what you do in each situation. One of my favorite features of git-flow is housekeeping, for features when you close them it merges to develop and destroys the branch, when you do a hotfix it merges to master and develop and destroys…

I haven't used it yet, but I have to agree that forcing a team through the same general process would be a very big win.

Would a single member of the team (the release manager) be doing it all though, and the rest of the team would only be pushing to the development branch? The release manager would maybe pull for hotfixes, but it would always be the release manager doing the work (or his proxy).

Re: Why aren't you using git-flow?

#37

Post by rlpb »

kscaldef wrote: post #29
bobbywilson0 wrote: post #11

Earlier quoted context omitted.

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.

My question is, why is this (develop/master) better than master/release branches? Or master/qa/production? Or do you view that as just an arbitrary choice of names (since there's nothing special about the master branch in git)?

I would prefer not calling any branch master when using a specific scheme like this. It's confusing. Master of what? The master development branch? The master release branch? Better to name each branch specifically.

Re: Why aren't you using git-flow?

#38

Post by lnguyen »

jerf wrote: post #26
brown9-2 wrote: post #10

Earlier quoted context omitted.

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…

There's a psuedo-branch in master, which is "everything since the latest commit that has been pushed out". (This is my own terminology, so don't go Googling for it.) This is the branch that becomes "real" once pushed to the public, and that's when you can no longer rewrite the history without hurting things. If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in)…

There's no need for any custom terminology: Your master branch isn't a pseudo-branch. It's just another branch that happens to live in your local repository and shares the same name as the remote repository's branch that it tracks.

Re: Why aren't you using git-flow?

#39

Post by lnguyen »

drothlis wrote: post #15
brown9-2 wrote: post #10

Earlier quoted context omitted.

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…

Yes, you can create a new branch from any tag (or indeed any commit).

Going a bit further, when you create a branch, what you're specifying is a starting point for that branch which will be a commit. The commit may be referenced via a tag, as the head of a branch (when you give the branch name or the head of the current one by default), or by the commit itself.
Post reply on HN