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

GitFlow considered harmful

endoflineblog.com

Post reply on HN
Print view View original

51–60 of 342 posts

Re: GitFlow considered harmful

#51

Post by Mithaldu »

sytse wrote: post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

Looking at the recent history i can see how you'd come to like it. You seem to mostly be doing merges or documentation changes, which probably means you don't have to do a lot of history spelunking to fix bugs caused months ago.

Are you sure your developers feel the same as you do? Are you sure they're willing to be open enough to you about their misgivings?

Re: GitFlow considered harmful

#52

Post by briHass »

perlgeek wrote: post #15

A reason that we are switching from full git flow to a reduced model (basically one master branch + feature branches, occasional hotfix branches) is that git flow isn't compatible with continuous integration and continuous delivery. The idea of CI is that you integrate all commits, so you must integrate the develop branch - build the software, run the tests, deploy it to a production-like environment, test it there t…

Is this more a limitation of your CI/deployment tools? What we do (not saying it's the true way) is have TeamCity automatically build both master (production code + hotfixes) and development branches. Our deployment tool (Octopus) can just grab a particular release (e.g. 1.1.500=master 1.1.501=development) and send it to the server for testing. Hotfixes would be committed to master and tested with a build from there.

I guess this does open up the possibility that merging master (with hotfixes) back into development could cause a regression, but we certainly try to keep hotfixes minimal and simple.

Now database changes...that's the real pain point. Both master and development need their own DB to apply changes scripts to. Otherwise, deltas from development make testing master an issue.

Re: GitFlow considered harmful

#53

Post by solutionyogi »

realityking wrote: post #49
chaitanya wrote: post #41

I have never understood why people hate merge commits so much. Their advantages are not insignificant: you know when a feature got merged in master, its much easier to revert a feature if you have a merge commit for it, much easier to generate a change log with merge commits, and you have none of the problems that pushing "cleaned up" histories will have: https://www.mail-archive.com/dri-devel@lists.sourceforge.net..…

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

Then rebase interactive is your friend. Clean up your feature branch BEFORE merging in to the release branch.

Re: GitFlow considered harmful

#54

Post by btreecat »

To me (a mercurial user mostly) this is kind of like a "no duh" article having never read the original "gitflow."

I think that is because I am used to using hg's branches, bookmarks, and tags for different use cases.

If I want to mark a revision as a particular release number (which is something we don't really do here but I can see the value) then I would use hg tag. Tag's are permanent.

If I want to mark a revision as "production" and then have some automated process take over based on the the updated info, I would use hg bookmark. Bookmarks are the closest equivalent to git's branches. Bookmarks can be updated to a new revision or removed.

If I wanted to work on a parallel branch of development for an experimental feature or if I am attempting to upgrade some dependencies, I can use hg branch. This creates a named branch in the code base which is permanent. This branch can eventually be either closed or merged back into the main.

Re: GitFlow considered harmful

#55

Post by Touche »

simias wrote: post #43
Touche wrote: post #35

Earlier quoted context omitted.

Why not just use tags?

You might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).

Sure, you can do that with tags. Branch off from your tag, cherry-pick your commits, push and if tests pass create a new tag.

Re: GitFlow considered harmful

#56

Post by chaitanya »

realityking wrote: post #49
chaitanya wrote: post #41

I have never understood why people hate merge commits so much. Their advantages are not insignificant: you know when a feature got merged in master, its much easier to revert a feature if you have a merge commit for it, much easier to generate a change log with merge commits, and you have none of the problems that pushing "cleaned up" histories will have: https://www.mail-archive.com/dri-devel@lists.sourceforge.net..…

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

So do a clean up before broadcasting your history to others. See https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

One trick that can really help with this is `git commit --amend`, which allows you to amend the last commit. If you encounter a bug or a typo in the your last commit, add your fix to the index and then do `git commit --amend`. This will replace your last commit with a new one that contains your latest fix. Of course, this should only be done if you did not push your last commit to remote.

For fixes to earlier commits, I don't bother much, and just live with the trivial commit. Though if I end up making several trivial commits in one setting, I do a cleanup and merge this fixes in one commit before pushing.

Re: GitFlow considered harmful

#57

Post by tokenizerrr »

Mithaldu wrote: post #4
tokenizerrr wrote: post #3

I like to be able to (temporarily) revert an entire feature branch, which merge commits help with. Is there a way to easily do this without them?

If i understand you right, you want to do this: - Checkout master. - Start an interactive rebase of master onto the last commit before the series of commits you wish to remove. - Mark all the commits you don't care about as "skip". - Let the rebase run and resolve conflicts on the way, the same as you'd do with your current work flow.

This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete I revert the revert I just made and merge the feature branch again.

Re: GitFlow considered harmful

#58

Post by Mithaldu »

tokenizerrr wrote: post #57
Mithaldu wrote: post #4

Earlier quoted context omitted.

If i understand you right, you want to do this: - Checkout master. - Start an interactive rebase of master onto the last commit before the series of commits you wish to remove. - Mark all the commits you don't care about as "skip". - Let the rebase run and resolve conflicts on the way, the same as you'd do with your current work flow.

This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete…

You introduce explicit revert commits?

Re: GitFlow considered harmful

#59

Post by tokenizerrr »

solutionyogi wrote: post #50
sytse wrote: post #40

Earlier quoted context omitted.

My personal opinion is that it breaks history and CI tests for all the feature branches. But at GitLab we encountered customers that insisted on having a linear history after migrating from SVN. Therefore there is a function in the UI of GitLab EE to rebase a merge request when accepting the merge request. See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

A CI test result is tied to a particular commit hash. If you change this commit hash the CI test result will no longer be tied to that one commit.

Re: GitFlow considered harmful

#60

Post by tokenizerrr »

Mithaldu wrote: post #58
tokenizerrr wrote: post #57

Earlier quoted context omitted.

This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete…

You introduce explicit revert commits?

Yes, this is a feature of git: https://git-scm.com/docs/git-revert

I don't think rewriting the history of public branches is a good idea.

Post reply on HN