13 ms·

GitFlow considered harmful

464 points by edofic 11y ago

Mithaldu 11y ago
I adore every person who advocates a mostly linear history and is able to elucidate that efficiently and elegantly. :D
- ionforce 11y ago
  Me too. I'm on team linear history and I still haven't gotten off my bum to make an article/presentation about it. But I'm with you, brother!
  - nsfyn55 11y ago
    +1
tokenizerrr 11y ago
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?
- Mithaldu 11y ago
  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.
  - purephase 11y ago
    Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags. While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway). [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
  - tokenizerrr 11y ago
    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.
    - Mithaldu 11y ago
      You introduce explicit revert commits?
      - tokenizerrr 11y ago
        Yes, this is a feature of git: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert I don't think rewriting the history of public branches is a good idea.
        Mithaldu 11y ago
        Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me.
        tokenizerrr 11y ago
        Wow, way to be literally the opposite of constructive. Grow up.
        Mithaldu 11y ago
        We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.
        11y ago
- jerf 11y ago
  It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be. I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing. I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones. That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.
LukeB_UK 11y ago
Anyone else fed up of articles using "considered harmful" in the title? Especially when it's just that the author doesn't like that thing.
- mayoff 11y ago
  http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html
- pskocik 11y ago
  Yup.
- cleaver 11y ago
  At this point, I just assume that "X considered harmful" contains an element of satire. That's not always the case, but I have no problem saying "Satirical 'Considered Harmful' Articles Considered Not Harmful".
- isaacremuant 11y ago
  I am. I resent such articles unless they come from a very clear eminence who has public and verifiable evidence to support his case. This seems more of a: "This tool is popular but it doesn't work for me so it's bad". In fact, as you say, he dislikes the tool (from the get go): > I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste. Throwing my two cents. There's no perfect methodology and teams that communicate and adhere to a set of standards will probably find a good way to work productively with git. They can always be helped with scripts like the gitflow plugin or some other helper if they think the possibility of human errors is big. I also have anecdotal experience of working with and without and, being fine with either although I do appreciate git flow in any project that starts getting releases and supporting bug fixes, hot fixes and has been living for a while so it incorporate orthogonal features at the same time.
ryanthejuggler 11y ago
> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful" articles. It seems to me like you can spout any opinion under a title of that format and generate lingering doubt, even if the article itself doesn't hold water. Not to generalize, of course--not all "XXX considered harmful" articles are harmful. They generally make at least some good points. I just think the title format feels kind of clickbaity at this point. That said, kudos to the author for suggesting an alternative rather than just enumerating the shortcomings of GitFlow.
- giulianob 11y ago
  Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.
  - ryanthejuggler 11y ago
    Ironically, for that reason, GitFlow would work better in Mercurial. Go figure.
    - davidism 11y ago
      HgFlow already exists and is actively developed: https://bitbucket.org/yujiewu/hgflow/wiki/Home https://bitbucket.org/yujiewu/hgflow/wiki/Home. It even goes above and beyond GitFlow and adds generalized streams and sub-streams. I've never had to use those extra features, but the core model works well.
  - glandium 11y ago
    Mercurial branches are not meant to be used for short-lived feature branches, though. As "hg branch" puts it: "branches are permanent and global, did you want a bookmark?".
talles 11y ago
I second the feeling of GitFlow being over-engineering: http://blog.talles.me/that-git-flow.html http://blog.talles.me/that-git-flow.html
- marvel_boy 11y ago
  Absolutly agree, to much complexity.
- CrystalGamma 11y ago
  little typo: vMAJOR.MINOR.PATH => vMAJOR.MINOR.PATCH And I must say I agree with all you say in that post.
  - talles 11y ago
    A downside of always typing, never copying and paste. Thanks!
jacobparker 11y ago
> I thought it was a weird, over-engineered solution to a non-existent problem. To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned. (To be clear, I am not a fan of git flow.) If anyone is interested in truly understanding git, start here: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
- matthiasv 11y ago
  His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.
  - jacobparker 11y ago
    I should have been more clear - I agree that its more complicated. My point was that regardless, it seems to resonate. I believe its because the complications look useful at a glance and layering a rigid model on top of git frees you from having to consider its full scope of possible operation. (I believe that git flow is definitely better than "everyone does things their way", and that's one competing "rule-book" for a team new to git.) I'm pretty confident that understanding the tool better will help you to judge how to use it more effectively. The best way to understand git is to understand its data-model.
omouse 11y ago
The only thing GitFlow had going for it is that it has a clearly written article about it with pictures that explain how it works. That's it; the freedom of git and being able to define what works for you is too much for people and they think they need to turn development back into Subversion-style or desktop-release style.
- ryanthejuggler 11y ago
  I agree with you, with one addition in GitFlow's favor--it standardizes how your team works. When you have multiple team members collaborating on a project, a poor standard is better than none at all.
perlgeek 11y ago
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 too. So naturally, most testing happens in that environment; and then you make a production release starting from the master branch, and then install that -- and it's not the same binary that you tested before. Sure, you could have two test/staging environments, but I don't think I could get anybody to test their features in both environments. That's just not practical.
- briHass 11y ago
  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.
  - krisdol 11y ago
    At my last company, that was 60 live feature/bug branches, each having to be built by CI before being mergeable. The feedback loop was huge, and at the end of the day, the quality of the product did not improve over SVN. develop was a shit show and twice a month, master would be as well. Ultimate they decided to move to team branches, where each team branch was free to operate how they want so long as the team branch itself built successfully before merging into master. I think most teams adopted the more natural-feeling GitHub Flow. Personally, for me it's not even the god-awful history that makes me despise gitflow, but its reliance on additional tools to effectively manage the process. This should be a huge red flag to anyone seeking to change a process, and it's complained about a lot. Cowokers not knowing what git-flow is doing under the covers is dangerous. I consider myself pretty versatile with git at this point, but I have no idea what the tool does under the covers. I'm sure I could find out; however, when you're handed a piece of software, generally you learn the contract/api it provides, but most of us aren't going to delve into the implementation details.
ninjakeyboard 11y ago
You don't need to implement ALL of gitflow - I see it as scalable. Master should always be latest production code, development branch contains all code pre-release. That's the core. The other branches let you scale gitflow - if you need to track upcoming release bugfixes etc, you can use a release branch. A team of maybe 6 or 7 would likely start to need a release branch. Feature branches at this point are best left local on the developers repository. They rebase to fixup commits, and then merge those into develop when they're ready. If you get into bigger teams - like maybe 6 agile teams working on different larger features, then you can introduce feature branches for the teams to use on sprints to keep the work separate. The issue with gitflow is the lack of continuous integration, so I personally like to get teams to work only on a develop branch during sprints and use feature toggles to commit work to the develop branch without breaking anything. As I see it, gitflow and CI are at odds and that's my biggest gripe with integrating lots of feature branching for teams - everyone has to integrate at the end of the day. So I believe the model can and should be scaled back as far as possible, using only develop and master and release as primary workflow branches, introducing the others when the need arises - doing it just because it says so in the doc isn't the right approach.
deleted 11y ago
[deleted]
rattray 11y ago
I actually thought GitHub Flow was more commonly used, as it's lighter-weight: [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html [2] https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/
t_fatus 11y ago
I think it greatly depends of the size of your team: if you're alone you have one branch, if you're two you may have 3 branches, each for one of you + master, if you're four you start to use feature-based branches.. It might be fun to compute the number of branches needed as a function of the number of devs in your team.
sytse 11y ago
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 in each-others way. No longer having a linear history is an acceptable consequence. In reality the history was never linear to begin with. It is better to have a messy but realistic history if you want to trace back what happend and who did and tested what at what time. I prefer my code to be clean and my history to be correct. I prefer to start with GitHub flow (merging feature branches without rebasing) and described how to deal with different environments and release branches in GitLab Flow https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/
- brento 11y ago
  There is nothing wrong with rebasing a feature branch imho. Feature branches should be considered ephemeral. But it probably depends on your team and project size.
  - sytse 11y ago
    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 http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
    - solutionyogi 11y ago
      Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.
      - tokenizerrr 11y ago
pskocik 11y ago
I think he makes a valid point about how it's not necessary to have both develop and master if you use tags. On the other hand, I think the `--no-ff` merges is what git-flow got right. The separation of features into their own branches is useful. It's basically about grouping related commits together. You can always render the history in a way that looks prettier and even if you can't--the history doesn't need to look pretty, the final product does.
- ionforce 11y ago
  I disagree with you that the history doesn't look pretty. Have you not found the ability to investigate/audit bugs hindered by non-linear histories?
jaimebuelta 11y ago
The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness" - branches: Work in progress. - develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world. - master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests. As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...
- mmgutz 11y ago
  I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.
  - Touche 11y ago
    Why not just use tags?
    - simias 11y ago
      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).
      - Touche 11y ago
        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.
    - ryanbrunner 11y ago
      We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)
Anderkent 11y ago
Most of the merges in his first pictures aren't even fast-forwardable, so his complaint about no-ff seems.. weird? You should still rebase your feature branch on top of whatever you're merging into whenever you can, even if you're using git-flow. That's just common sense. When you do, your history looks almost the same as in his 'pretty graph', there's just one more 'link' back to the previous feature merge. The advantages of this additional context are important. Firstly, you can get a compressed view of only the features that were merged (without detailed commits) with something like `git log --first-parent`. I guess the only way to do that in OPs approach is `git log | grep 'SPA-'`? Rather... unreliable. Using no-ff also means you don't have to do the silly thing of putting your issue name / branch name in every commit title. Titles are pretty short already, having to allocate ~10% of it to tracking the name of the branch is just wasteful. With no-ff it's obvious which feature the commit is for (the branch name in the merge). If your tool fails to present that in a reasonable fashion, that's disappointing, but the data includes this context and that's the most important thing. As to the master/develop split, yeah I could be convinced it's unnecessary. Still, I think it's convenient to have a clear separation of 'this code is in production', 'this code is in development'. If you just make a release branch then merge it into develop, you have to know the exact tag before being able to find the latest release. 'master' being the alias for 'latest release' is fine.
leni536 11y ago
I never used gitflow so I could be wrong but the main problem with logging seems to be this: Gitflow thinks about branches as lanes. Git branches are actually labels. What's the difference? In the gitflow model every commit belongs (implicitly) to a branch (or a lane). Git branches don't work that way. One could actually implement "lane" as an additional commit metadata and tweak git-log (and other git utilities) to always show lanes in straight lines in the graph.
erikb 11y ago
It's not really harmful just because it's too much overhead for small projects. If you have a huge project I'd assume that it's much harder to read history anyway, and then a more complex pattern of development is reasonable.
Touche 11y ago
> All other branches (feature, release, hotfix, and whatever else you need) are temporary and only used as a convenience to share code with other developers and as a backup measure. They are always removed once the changes present on them land on master. From an open source developer's perspective I need more "eternal" branches because I need to plan future releases. Putting everything into master makes the decision for me (if I have a breaking change I have to bump a major version even if maybe I want to delay doing that).
solutionyogi 11y ago
So let me get this straight. He is suggesting to use 90% of what GitFlow suggests (feature/hotfix/release branches) but doesn't like the suggestion of non-fast-forward merge and master/Dev and that makes GitFlow harmful? I don't think I agree. I think having the Dev branch is useful. Consider this actual scenario at my current workplace. 1. We have 4 developers. Nature of the project is such that we can all work independently on different features/changes. 2. We have Production/QA/Dev environment. 3. When we are working on our individual features, we do the work in individual branches and merge in to Dev branch (which is continuously deployed).This lets us know of potential code conflicts between developers in advance. 4. When a particular feature is 'developer tested', he/she merges it into a rolling release branch (Release-1.1, Release-1.2 etc) and this is continuously deployed to QA environment. Business user does their testing in QA environment and provides sign off. 5. We deploy the artifacts of the signed off release branch to Production and then merge it in to the master and tag it. Without the development branch, the only place to find out code conflicts will be in the release branch. I and others on my team personally prefer the early feedback we can get thanks to the development branch. Advantages of an explicit merge commit: 1. Creating the merge commit makes it trivial to revert your merge. [Yes, I know it is possible to revert the merge but it's not exactly a one step process.] 2. Being able to visually see that set of commits belongs to a feature branch. This is more important to me (and my team) than a 'linear history' that the author loves. We have diverted from GitFlow in only one way, we create all feature/release/bugfix branches from 'master' and not 'develop'. Now, don't get me wrong, GitFlow is not simple but it's not as complicated as author seems to suggest. I think the author was better served with article title like 'What I don't like in GitFlow'.
chaitanya 11y ago
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/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... The main disadvantage, as the article rightly points out, is that it makes it much harder to read the history. But that's easily solved with a simple switch: --no-merges. It works with git-log, gitk, tig, and probably others too. Use --no-merges, and get a nice looking linear history without those pesky merge commits.
- realityking 11y ago
  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.
  - solutionyogi 11y ago
    Then rebase interactive is your friend. Clean up your feature branch BEFORE merging in to the release branch.
  - chaitanya 11y ago
    So do a clean up before broadcasting your history to others. See https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html 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.
  - 11y ago
mpdehaan2 11y ago
Posted a link to this prior blog of mine in article comments also - http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe... - but I'm a huge fan of rebase and topic branches. One main branch is great, and also if working with a large number of contributors I really like a clean history, and makes things much easier to review. It's kind of a shame something got branded with a slick name like "GitFlow", when "doing it the way you ought to be doing it" doesn't have a slick name :)
btreecat 11y ago
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.
radicalbyte 11y ago
I see GitFlow as a pragmatic workflow customized to cloud-based software. Master is auto-deployed, and Dev acts as insurance. We're currently having lots of success with this: * Always work in a feature branch. * Pull master + rebase feature branch when done. * Merge to master with --no-ff --edit and include a summary. Rebasing feature branches keeps them readable and avoids continuous merges. Disable fast-forward keeps the log for /master abstracted to feature-level, but the details are available in the graph. Major releases are branched, minors (bugfixes) are tagged. Bugfixes are made in master and cherry-picked into the release where possible. Currently our CI build only works on /master, but in the coming month it'll build all feature branches which have been pushed to the main repository. This is very similar to how Perforce streams work, but it's distributed. If you really hate distributed version control and love GUIs then I can recommend Perforce.
menssen 11y ago
I have come to actually like the two permanent branches approach. I know that for any repository that follows this model that: * "master" is the current stable release * "develop" is the current "mostly stable" development version The first time you clone a repository this is an extremely helpful convention to quickly get your head around the state of things. If you're doing it right (and don't use --no-ff, which I agree is unreasonable), I can't think of a scenario where this causes extra merge commits. Merges to master should always be fast forward merges.
- jives 11y ago
  We follow this model. I like thinking of "develop" as an integration branch, and "master" as an always-deployable gold master. And yep, develop -> master merges are always fast-forward merges.
Bahamut 11y ago
One thing that bothers me about GitFlow is that it mangles history with merges. Sometimes it becomes tricky to debug issues when history was created with GitFlow. I would rather branch off of master, bring changes in via git am or rebasing when ready, then tag a release when it is ready to be released. If there is something wrong with master, the tagged releases serve as easy points to branch off of.
- deleted 11y ago
  [deleted]
- pacquiao882 11y ago
  I think it depends on the project's structure and team discipline. I tend to prefer straight lines in the history where a single feature or a group of similar functions are linear.
uzero 11y ago
Writing considered harmful posts is considered harmful - I hate these so much.
darylteo 11y ago
Curious here: has anyone tried using GitLab + forks to replace development branches? Would it needlessly overcomplicated?
- sytse 11y ago
  You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.
  - lgp171188 11y ago
    If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.
    - sytse 11y ago
      Please let me know what you think we should improve to support that workflow better. Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.
      - lgp171188 11y ago
        I have already created a feature request here - http://feedback.gitlab.com/forums/176466-general/suggestions/8483233-support-integration-manager-workflow-which-is-avai http://feedback.gitlab.com/forums/176466-general/suggestions... The main assumption in the Integration-Manager workflow is that code from repositories of other users is always pulled by the owner of the current repository as and when appropriate. So if dev1 and dev2 are working on the same feature in 2 different forks of the main repository, dev1 has to pull commits from dev2 that are needed in his/her fork and dev2 has to do the same in his/her fork. Once the feature is complete, the merge request is created from one of the 2 forks. Yes it is harder to mention issues, but that can be done in the message of the merge commit. Since forks are essentially equivalent to branches in this workflow, I usually don't mind referring to issues in the individual commits itself which would link to the correct issue on getting merged to the main repository. We do this with our team's projects hosted on Bitbucket, ymmv.
nsfyn55 11y ago
I have had this ideological debate about "fast forwarding" more times that I can count. I agree with the author "no-ff" is silly. I've been working on professional software teams for over a decade. When I encountered fast forwarding/rebasing it was absolutely a breath of fresh air. I've been using git now for 5 years and I have not encountered a single instance where using either of these tools has presented any sort of problem. I can't remember a week where having a concise, readable history hasn't proven its value. I also can't remember a single time I've said "Man I'm glad I had all these merge commits around they really saved my proverbial bacon" From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. It gives them something to do between harping on whether your behavior is in the correct "domain", deciding if a list comprehensions are truly "pythonic", and spending that extra month perfecting the event sourcing engine to revolutionize the "contact us" section of your site.
- JanezStupar 11y ago
  Because you do not need something, then it has to be useless. > From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. Incredible irony.
  - nsfyn55 11y ago
    well can you provide the killer use case that none of us can live without? I mean its certainly possible that in some tiny fraction of cases I might say "man I could fix this a lot easier if I had the merge commit" its just in the 10,000's of examples that form my experience I haven't stepped on that particularly landmine yet. Even with that said, my development philosophy compels me to choose "Simplicity over Completeness" and is utilitarian to the core. I will chose whatever is most effective in the vast majority of cases. Some folks look at "Source Control History" as some pristine, historical record of how things went down. Since I am not an accountant or auditor this has little value to me. It encumbers the day to day to optimize for a case that is almost certain to never happen. A first-order approximation of the history that optimizes for the day-to-day needs of an organization is far more suitable in almost every case. I use the term "local team pedant" its not a bad thing. Some folks just have a need for things to be "complete" and feel compelled to do so for irrational(usually expensive) reasons. In my own experience the person that is the "no rebase/ never fast forward" cheerleader can never give a solid objective answer as to what the benefit is. Its usually always something like what this no-ff-er suggests(http://walkingthestack.blogspot.com/2012/05/why-you-should-use-git-merge-no-ff-when.html http://walkingthestack.blogspot.com/2012/05/why-you-should-u...) . Things like "I can see whats on a branch, etc." That in itself is not a justification. Its just words. If you could someone how demonstrate how this reduces development costs or offers a better way to organize work and is simultaneously better than the more idiomatic alternatives then I'm all for it.
jwr 11y ago
That's the first time I heard of GitFlow. People seriously do software development this way? I find that hard to believe. What the author describes is fairly close to what I've been using in a number of companies now for the last 9 years or so. Whether to rebase is a personal preference. I tell developers to always rebase local work before committing. Unobserved changes might as well not exist (if a tree falls in the forest and no one is there to hear it falling, does it make a sound?), so if you haven't pushed your work, rebase it. No one cares when you did the work. As for feature branches, it depends. If the history is clean and there aren't too many at one time, we might merge without rebasing. But I still prefer to clean up the commit history and rebase. I don't understand the obsession with "true history". History is written by victors, in this case — resulting work/code.
dimino 11y ago
I personally find git flow to be a wonderfully elegant and simple way of handling a project in git. Not everything is perfect, but I consider git flow to be much like PEP8. It's almost always a good idea to do it the git flow way, unless you have a very specific and documented exception, in which case do that instead. To me what matters more is the consistency. Also, the attitude and tone of this article straight up stinks.
Finster 11y ago
I can count on zero hands the number of times I've needed to solve a problem by navigating the branch tree. I've lost count of the number of times that two eternal branches and feature branches with pull requests (+ code review) has saved major flaws from getting to production. The develop branch is perfect for automatically deploying our bleeding edge to our test server. Although, if we move to a more continuous deployment approach, we may transition away from two eternal branches. But when GitFlow was first written about, continuous deployment really wasn't the trend that it is now. Methods will continue to evolve...
dankohn1 11y ago
We use a more extreme version of rebasing feature branches before merging into master: we squash the features into a single commit when merging to master. The reason is that we don't care about the (sometimes hundreds of) commits that made up a feature. What matters is that it works as designed and passes tests. If we merge a feature to master and then need to revert it, we will revert the whole feature. This also allows us to keep merging master into feature branches, (where there is only a single commit that might need to be manually merged) instead of rebasing feature branches on master (in which case it can be necessary to manually merge multiple intermediate commits). What cleared up git merge --squash for me was a comment showing that: git checkout master git merge --squash feature is the equivalent of doing: git checkout feature git diff master > feature.patch git checkout master patch -p1 < feature.patch git add .
- Thrymr 11y ago
  That loses a lot of information, though. If you want to bisect to find a particular bug, tracking it down to the merge is a good start, but I'd rather have the actual commit (from the maybe hundreds) that went into the merge. Sure, you can revert the feature, but what if you want to fix the bug? Git history has a lot of commits. That's OK.
  - dankohn1 11y ago
    Yes, the downside of a much more streamlined commit log is that we do throw out information.
jguegant 11y ago
What about using merging when it comes to the feature branches but rebase when pulling (git pull --rebase)? Is it that harmful to rewrite the history for your local changes?
scottious 11y ago
I don't see why there has to be "this is harmful" and "this is a better way". I've used all kinds of branching models... I've used just a master branch and you commit directly to master. I've used full git-flow. I think the branching model you use is dependent on the people and the project. But really no matter which model I've used it seemed to me to be fine... And if it wasn't fine, we extended it to meet our requirements.
jedbrown 11y ago
Git-flow indeed has serious problems. This author is proposing a particular subset of gitworkflows(7). https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html https://www.kernel.org/pub/software/scm/git/docs/gitworkflow... I like subsetting gitworkflows(7) because you can incrementally add process when the tangible benefits (like increased reliability and experimental access for eager users) outweigh their process cost (which depends on team experience). I wrote about these issues here: http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.an... This diagram represents a workflow that uses 'maint', 'master', and 'next' branches. http://59A2.org/files/simplified-gitworkflows7.svg http://59A2.org/files/simplified-gitworkflows7.svg
rdsubhas 11y ago
A single eternal master works for a Continuously Deployed app/site. Not for any other project where maintenance releases are a norm. This includes stuff strict API compatibility projects, semantically versioned frameworks/plugins/libraries, many forms of desktop/offline apps, some android apps, most enterprise apps, etc - more or less where developers don't have the liberty to thrust the latest master on their users. I'm not against CD, and not a big fan of Git Flow either. But different things have their own uses. I'm really liking GitHub Flow and GitLab Flow though!
- habitue 11y ago
  Right, when you need to maintain (and patch) old versions of a piece of software, having eternal release branches is necessary. The fixes on those old versions often don't ever want to be merged back to master because the code is very different in more recent versions.
nycticorax 11y ago
It seems like one of the ironies of git-flow is that it would actually work better if you used it with Mercurial rather than Git, because Mercurial stores what branch you were on when you made a commit. This means that a tool could automatically look at the Mercurial commit tree and figure out which swimlane each commit belongs in, and use this information to draw a commit history tree that wasn't such a mess. I apologize for the self-promotion, but this answer on Stack Overflow (and the question) talks about this difference between Git and Mercurial, and includes links to articles that explain it better than I could: http://stackoverflow.com/a/26784550/1013442 http://stackoverflow.com/a/26784550/1013442
dicroce 11y ago
Even though I could frequently commit on feature branches, I usually don't. Hence, when I merge feature branches I don't have crazy messy histories that I feel it necessary to rewrite.... Works for me.
songshu 11y ago
I wish GitFlow had not called that branch "master", and had called it "released" or "production" instead. It's really useful to have a branch which you know always exactly represents the code running in production. You can keep an IDE pointed at somewhere and update when you need to without worrying about tags or whatever. This is the one part of it I've tried to sell to colleagues, which would have been easier if it had a better name.
gouggoug 11y ago
GitFlow is also in my opinion a bad flow as it does end up with a merge commit spaghetti over time. Merge commits are great. They are here to group a list of commits into a logical set. This logical set could represent one "feature", but not necessarily. It is up to you to decide whether commits A B C D should or shouldn't be grouped by a merge commit. Merge commits also make regression searchs (i.e. git bisect) a lot faster. And to top it of, they will make your history extremely readable, but that is granted you merge correctly... and that is where git rebase and git merge --no-ff come into play. At my company, every developer must rebase their topical branch on top of the master branch before merging. Once the topical branch is rebased, the merge is done with a --no-ff. With this extremely easy flow, you end up with a linear history, made of a master branch going straight up and only everyonce in a while a merge commit. Our commit history looks like this: *-------------*---------*---------*----------*----*-------> \-----------/ \---------/ \--/ Following the simple rule "commit, commit, commit..., rebase, merge --no-ff" avoided the merge spaghetti a lot of people compain about. Although, I have to admit our repository is small (6583 commits to date). This works even when multiple devs work on the same branch: they must get in touch on a regular basis, rebase the branch they are working on and force push it. Rewritting history of topical branches is only bad if it is not agreed on. As long as it is done in a controlled manner nothing's wrong with it. Another rule we follow is to always "git pull --rebase" (or git config branch.autosetuprebase=true). Our approach might not, however, scale for larger teams or open source projects.
mml 11y ago
Ever since I started getting involved in SCCM stuff, I've been astounded at how much breath and emotion people are eager to waste defending their choice, or technique or strategy or whathaveyou. SCCM system discussions should be banned on HN, as pointless and heated as vi vs. EMACS discussions.
nijiko 11y ago
Do what is easiest for you. 1. Merging vs Rebasing Open source projects should stick with Merging over cherry-picking and rebasing especially if you want others to contribute. Unless you feel fine doing all of the rebasing and cherry-picking for them. Otherwise, good luck gathering a large enough pool of people to contribute. Simplicity always wins here. 2. GitFlow vs X Once again do what is good for your company and the people around you. If you have a lot of developers having multiple branches is actually /beneficial/ as Master is considered ALWAYS working. Develop branch contains things that are ready to ship, and only things that are READY TO SHIP. So if your feature isn't ready yet, it can't go to develop, and it won't hit master. Your features are done in other branches. 3. Rewriting history Never do this. Seriously, it will come to bite you in the ass. 4. Have fun. Arguing is for people who don't get shit done.
orbitur 11y ago
I can distill my thoughts down to this: The time it takes to carefully rebase a branch onto another, and to compress commits for a feature into one, is still much longer than the time it takes for my eyes to pass over so-called "empty" merge commits. If I want to look at when a feature entered a branch, I can look at its merge commit. And the feature branches are there to show how a feature was built; bugs could be the result of a design decision that happened in one of the midway commits. I looked at OP's example pic in the blog, and I read all of his words, but I wasn't sold. His picture looks like a normal git history to me. It requires almost no effort to find what I'm looking for. And that's not even touching his rage against the idea of a canonical release branch (master). But that's for another day.
5outh 11y ago
On the main project I'm working on, the reason we have develop/master is mainly for hotfixes. We deploy once a week, but if we need to get something out the door quickly, we make a hotfix branch off of master, then merge it into both develop and master. This way, if we find something that needs to be fixed before the next release, but don't want to push half-done updates, we can seamlessly do it.
mcv 11y ago
Advising rebasing over explicit merges is dangerous and foolish. Rebasing does have its place, but you really need to know what you're doing. Also, I don't see his point about that messy history. I can see exactly what happened in that history (though the branch names could have been more informative). With multiple people working on the same project, feature branches will save your sanity when you need to do a release, and one feature turns out to not be ready.
juandazapata 11y ago
It's not confusing, maybe it's not suited for your particular case, as any other tool. There's no magic tool/process/etc that does it all for everybody. GitFlow has been working great for us. A team of 15 developers, working with feature branches, we have our CircleCI configured to automatically deploy the "develop" branch to our "QA environment", and our "master" branch to "production" environment. The "hotfix" and "release" are proven to be useful to us too; we just need to have effective communication with our team, so everybody rebase their feature branch after a merge in our main branches.
JulianMorrison 11y ago
The whole point of hotfixes is that they are relative to old code and that they alter what is considered the current version of that old release. Which is important when (as is typical in business) you have customers who are on specific releases and either haven't paid for the new hotness, or haven't integrated to it and don't yet want it. So absolute minimum you need one persistent branch per old release, if you ever hotfixed it and still have it deployed in the field. GitFlow falls over here, because it only has one master. But at least it does recognize the fact that repairing released code is different from pushing the unreleased state of the art forward.

464 points by edofic 11y ago

Mithaldu 11y ago

I adore every person who advocates a mostly linear history and is able to elucidate that efficiently and elegantly. :D

ionforce 11y ago
Me too. I'm on team linear history and I still haven't gotten off my bum to make an article/presentation about it. But I'm with you, brother!
- nsfyn55 11y ago
  +1

tokenizerrr 11y ago

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?

Mithaldu 11y ago
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.
- purephase 11y ago
  Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags. While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway). [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
- tokenizerrr 11y ago
  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.
  - Mithaldu 11y ago
    You introduce explicit revert commits?
    - tokenizerrr 11y ago
      Yes, this is a feature of git: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert I don't think rewriting the history of public branches is a good idea.
      - Mithaldu 11y ago
        Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me.
        tokenizerrr 11y ago
        Wow, way to be literally the opposite of constructive. Grow up.
        Mithaldu 11y ago
        We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.
        11y ago
jerf 11y ago
It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be. I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing. I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones. That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.

LukeB_UK 11y ago

Anyone else fed up of articles using "considered harmful" in the title? Especially when it's just that the author doesn't like that thing.

mayoff 11y ago
http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html
pskocik 11y ago
Yup.
cleaver 11y ago
At this point, I just assume that "X considered harmful" contains an element of satire. That's not always the case, but I have no problem saying "Satirical 'Considered Harmful' Articles Considered Not Harmful".
isaacremuant 11y ago
I am. I resent such articles unless they come from a very clear eminence who has public and verifiable evidence to support his case. This seems more of a: "This tool is popular but it doesn't work for me so it's bad". In fact, as you say, he dislikes the tool (from the get go): > I remember reading the original GitFlow article back when it first came out. I was deeply unimpressed - I thought it was a weird, over-engineered solution to a non-existent problem. I couldn't see a single benefit of using such a heavy approach. I quickly dismissed the article and continued to use Git the way I always did (I'll describe that way later in the article). Now, after having some hands-on experience with GitFlow, and based on my observations of others using (or, should I say more precisely, trying to use) it, that initial, intuitive dislike has grown into a well-founded, experienced distaste. Throwing my two cents. There's no perfect methodology and teams that communicate and adhere to a set of standards will probably find a good way to work productively with git. They can always be helped with scripts like the gitflow plugin or some other helper if they think the possibility of human errors is big. I also have anecdotal experience of working with and without and, being fine with either although I do appreciate git flow in any project that starts getting releases and supporting bug fixes, hot fixes and has been living for a while so it incorporate orthogonal features at the same time.

ryanthejuggler 11y ago

> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful" articles. It seems to me like you can spout any opinion under a title of that format and generate lingering doubt, even if the article itself doesn't hold water. Not to generalize, of course--not all "XXX considered harmful" articles are harmful. They generally make at least some good points. I just think the title format feels kind of clickbaity at this point. That said, kudos to the author for suggesting an alternative rather than just enumerating the shortcomings of GitFlow.

giulianob 11y ago
Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.
- ryanthejuggler 11y ago
  Ironically, for that reason, GitFlow would work better in Mercurial. Go figure.
  - davidism 11y ago
    HgFlow already exists and is actively developed: https://bitbucket.org/yujiewu/hgflow/wiki/Home https://bitbucket.org/yujiewu/hgflow/wiki/Home. It even goes above and beyond GitFlow and adds generalized streams and sub-streams. I've never had to use those extra features, but the core model works well.
- glandium 11y ago
  Mercurial branches are not meant to be used for short-lived feature branches, though. As "hg branch" puts it: "branches are permanent and global, did you want a bookmark?".

talles 11y ago

I second the feeling of GitFlow being over-engineering: http://blog.talles.me/that-git-flow.html http://blog.talles.me/that-git-flow.html

marvel_boy 11y ago
Absolutly agree, to much complexity.
CrystalGamma 11y ago
little typo: vMAJOR.MINOR.PATH => vMAJOR.MINOR.PATCH And I must say I agree with all you say in that post.
- talles 11y ago
  A downside of always typing, never copying and paste. Thanks!

jacobparker 11y ago

> I thought it was a weird, over-engineered solution to a non-existent problem. To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned. (To be clear, I am not a fan of git flow.) If anyone is interested in truly understanding git, start here: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

matthiasv 11y ago
His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.
- jacobparker 11y ago
  I should have been more clear - I agree that its more complicated. My point was that regardless, it seems to resonate. I believe its because the complications look useful at a glance and layering a rigid model on top of git frees you from having to consider its full scope of possible operation. (I believe that git flow is definitely better than "everyone does things their way", and that's one competing "rule-book" for a team new to git.) I'm pretty confident that understanding the tool better will help you to judge how to use it more effectively. The best way to understand git is to understand its data-model.

omouse 11y ago

The only thing GitFlow had going for it is that it has a clearly written article about it with pictures that explain how it works. That's it; the freedom of git and being able to define what works for you is too much for people and they think they need to turn development back into Subversion-style or desktop-release style.

ryanthejuggler 11y ago
I agree with you, with one addition in GitFlow's favor--it standardizes how your team works. When you have multiple team members collaborating on a project, a poor standard is better than none at all.

perlgeek 11y ago

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 too. So naturally, most testing happens in that environment; and then you make a production release starting from the master branch, and then install that -- and it's not the same binary that you tested before. Sure, you could have two test/staging environments, but I don't think I could get anybody to test their features in both environments. That's just not practical.

briHass 11y ago
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.
- krisdol 11y ago
  At my last company, that was 60 live feature/bug branches, each having to be built by CI before being mergeable. The feedback loop was huge, and at the end of the day, the quality of the product did not improve over SVN. develop was a shit show and twice a month, master would be as well. Ultimate they decided to move to team branches, where each team branch was free to operate how they want so long as the team branch itself built successfully before merging into master. I think most teams adopted the more natural-feeling GitHub Flow. Personally, for me it's not even the god-awful history that makes me despise gitflow, but its reliance on additional tools to effectively manage the process. This should be a huge red flag to anyone seeking to change a process, and it's complained about a lot. Cowokers not knowing what git-flow is doing under the covers is dangerous. I consider myself pretty versatile with git at this point, but I have no idea what the tool does under the covers. I'm sure I could find out; however, when you're handed a piece of software, generally you learn the contract/api it provides, but most of us aren't going to delve into the implementation details.

ninjakeyboard 11y ago

You don't need to implement ALL of gitflow - I see it as scalable. Master should always be latest production code, development branch contains all code pre-release. That's the core. The other branches let you scale gitflow - if you need to track upcoming release bugfixes etc, you can use a release branch. A team of maybe 6 or 7 would likely start to need a release branch. Feature branches at this point are best left local on the developers repository. They rebase to fixup commits, and then merge those into develop when they're ready. If you get into bigger teams - like maybe 6 agile teams working on different larger features, then you can introduce feature branches for the teams to use on sprints to keep the work separate. The issue with gitflow is the lack of continuous integration, so I personally like to get teams to work only on a develop branch during sprints and use feature toggles to commit work to the develop branch without breaking anything. As I see it, gitflow and CI are at odds and that's my biggest gripe with integrating lots of feature branching for teams - everyone has to integrate at the end of the day. So I believe the model can and should be scaled back as far as possible, using only develop and master and release as primary workflow branches, introducing the others when the need arises - doing it just because it says so in the doc isn't the right approach.

deleted 11y ago

[deleted]

rattray 11y ago

I actually thought GitHub Flow was more commonly used, as it's lighter-weight: [1] http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html [2] https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/

t_fatus 11y ago

I think it greatly depends of the size of your team: if you're alone you have one branch, if you're two you may have 3 branches, each for one of you + master, if you're four you start to use feature-based branches.. It might be fun to compute the number of branches needed as a function of the number of devs in your team.

sytse 11y ago

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 in each-others way. No longer having a linear history is an acceptable consequence. In reality the history was never linear to begin with. It is better to have a messy but realistic history if you want to trace back what happend and who did and tested what at what time. I prefer my code to be clean and my history to be correct. I prefer to start with GitHub flow (merging feature branches without rebasing) and described how to deal with different environments and release branches in GitLab Flow https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/

brento 11y ago
There is nothing wrong with rebasing a feature branch imho. Feature branches should be considered ephemeral. But it probably depends on your team and project size.
- sytse 11y ago
  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 http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
  - solutionyogi 11y ago
    Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.
    - tokenizerrr 11y ago

pskocik 11y ago

I think he makes a valid point about how it's not necessary to have both develop and master if you use tags. On the other hand, I think the `--no-ff` merges is what git-flow got right. The separation of features into their own branches is useful. It's basically about grouping related commits together. You can always render the history in a way that looks prettier and even if you can't--the history doesn't need to look pretty, the final product does.

ionforce 11y ago
I disagree with you that the history doesn't look pretty. Have you not found the ability to investigate/audit bugs hindered by non-linear histories?

jaimebuelta 11y ago

The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness" - branches: Work in progress. - develop: Code ready to share with others. It can break the build (merge conflicts, etc) and it won't be the end of the world. - master: This shouldn't be broken. It needs to point to a commit that has already been proven not break the build/pass all the required tests. As always, you need to find a balance with these things and adapt to the peculiarities of your code base and team. I really see them as suggestions...

mmgutz 11y ago
I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.
- Touche 11y ago
  Why not just use tags?
  - simias 11y ago
    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).
    - Touche 11y ago
      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.
  - ryanbrunner 11y ago
    We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)

Anderkent 11y ago

Most of the merges in his first pictures aren't even fast-forwardable, so his complaint about no-ff seems.. weird? You should still rebase your feature branch on top of whatever you're merging into whenever you can, even if you're using git-flow. That's just common sense. When you do, your history looks almost the same as in his 'pretty graph', there's just one more 'link' back to the previous feature merge. The advantages of this additional context are important. Firstly, you can get a compressed view of only the features that were merged (without detailed commits) with something like `git log --first-parent`. I guess the only way to do that in OPs approach is `git log | grep 'SPA-'`? Rather... unreliable. Using no-ff also means you don't have to do the silly thing of putting your issue name / branch name in every commit title. Titles are pretty short already, having to allocate ~10% of it to tracking the name of the branch is just wasteful. With no-ff it's obvious which feature the commit is for (the branch name in the merge). If your tool fails to present that in a reasonable fashion, that's disappointing, but the data includes this context and that's the most important thing. As to the master/develop split, yeah I could be convinced it's unnecessary. Still, I think it's convenient to have a clear separation of 'this code is in production', 'this code is in development'. If you just make a release branch then merge it into develop, you have to know the exact tag before being able to find the latest release. 'master' being the alias for 'latest release' is fine.

leni536 11y ago

I never used gitflow so I could be wrong but the main problem with logging seems to be this: Gitflow thinks about branches as lanes. Git branches are actually labels. What's the difference? In the gitflow model every commit belongs (implicitly) to a branch (or a lane). Git branches don't work that way. One could actually implement "lane" as an additional commit metadata and tweak git-log (and other git utilities) to always show lanes in straight lines in the graph.

erikb 11y ago

It's not really harmful just because it's too much overhead for small projects. If you have a huge project I'd assume that it's much harder to read history anyway, and then a more complex pattern of development is reasonable.

Touche 11y ago

> All other branches (feature, release, hotfix, and whatever else you need) are temporary and only used as a convenience to share code with other developers and as a backup measure. They are always removed once the changes present on them land on master. From an open source developer's perspective I need more "eternal" branches because I need to plan future releases. Putting everything into master makes the decision for me (if I have a breaking change I have to bump a major version even if maybe I want to delay doing that).

solutionyogi 11y ago

So let me get this straight. He is suggesting to use 90% of what GitFlow suggests (feature/hotfix/release branches) but doesn't like the suggestion of non-fast-forward merge and master/Dev and that makes GitFlow harmful? I don't think I agree. I think having the Dev branch is useful. Consider this actual scenario at my current workplace. 1. We have 4 developers. Nature of the project is such that we can all work independently on different features/changes. 2. We have Production/QA/Dev environment. 3. When we are working on our individual features, we do the work in individual branches and merge in to Dev branch (which is continuously deployed).This lets us know of potential code conflicts between developers in advance. 4. When a particular feature is 'developer tested', he/she merges it into a rolling release branch (Release-1.1, Release-1.2 etc) and this is continuously deployed to QA environment. Business user does their testing in QA environment and provides sign off. 5. We deploy the artifacts of the signed off release branch to Production and then merge it in to the master and tag it. Without the development branch, the only place to find out code conflicts will be in the release branch. I and others on my team personally prefer the early feedback we can get thanks to the development branch. Advantages of an explicit merge commit: 1. Creating the merge commit makes it trivial to revert your merge. [Yes, I know it is possible to revert the merge but it's not exactly a one step process.] 2. Being able to visually see that set of commits belongs to a feature branch. This is more important to me (and my team) than a 'linear history' that the author loves. We have diverted from GitFlow in only one way, we create all feature/release/bugfix branches from 'master' and not 'develop'. Now, don't get me wrong, GitFlow is not simple but it's not as complicated as author seems to suggest. I think the author was better served with article title like 'What I don't like in GitFlow'.

chaitanya 11y ago

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/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net... The main disadvantage, as the article rightly points out, is that it makes it much harder to read the history. But that's easily solved with a simple switch: --no-merges. It works with git-log, gitk, tig, and probably others too. Use --no-merges, and get a nice looking linear history without those pesky merge commits.

realityking 11y ago
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.
- solutionyogi 11y ago
  Then rebase interactive is your friend. Clean up your feature branch BEFORE merging in to the release branch.
- chaitanya 11y ago
  So do a clean up before broadcasting your history to others. See https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html 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.
- 11y ago

mpdehaan2 11y ago

Posted a link to this prior blog of mine in article comments also - http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe... - but I'm a huge fan of rebase and topic branches. One main branch is great, and also if working with a large number of contributors I really like a clean history, and makes things much easier to review. It's kind of a shame something got branded with a slick name like "GitFlow", when "doing it the way you ought to be doing it" doesn't have a slick name :)

btreecat 11y ago

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.

radicalbyte 11y ago

I see GitFlow as a pragmatic workflow customized to cloud-based software. Master is auto-deployed, and Dev acts as insurance. We're currently having lots of success with this: * Always work in a feature branch. * Pull master + rebase feature branch when done. * Merge to master with --no-ff --edit and include a summary. Rebasing feature branches keeps them readable and avoids continuous merges. Disable fast-forward keeps the log for /master abstracted to feature-level, but the details are available in the graph. Major releases are branched, minors (bugfixes) are tagged. Bugfixes are made in master and cherry-picked into the release where possible. Currently our CI build only works on /master, but in the coming month it'll build all feature branches which have been pushed to the main repository. This is very similar to how Perforce streams work, but it's distributed. If you really hate distributed version control and love GUIs then I can recommend Perforce.

menssen 11y ago

I have come to actually like the two permanent branches approach. I know that for any repository that follows this model that: * "master" is the current stable release * "develop" is the current "mostly stable" development version The first time you clone a repository this is an extremely helpful convention to quickly get your head around the state of things. If you're doing it right (and don't use --no-ff, which I agree is unreasonable), I can't think of a scenario where this causes extra merge commits. Merges to master should always be fast forward merges.

jives 11y ago
We follow this model. I like thinking of "develop" as an integration branch, and "master" as an always-deployable gold master. And yep, develop -> master merges are always fast-forward merges.

Bahamut 11y ago

One thing that bothers me about GitFlow is that it mangles history with merges. Sometimes it becomes tricky to debug issues when history was created with GitFlow. I would rather branch off of master, bring changes in via git am or rebasing when ready, then tag a release when it is ready to be released. If there is something wrong with master, the tagged releases serve as easy points to branch off of.

deleted 11y ago
[deleted]
pacquiao882 11y ago
I think it depends on the project's structure and team discipline. I tend to prefer straight lines in the history where a single feature or a group of similar functions are linear.

uzero 11y ago

Writing considered harmful posts is considered harmful - I hate these so much.

darylteo 11y ago

Curious here: has anyone tried using GitLab + forks to replace development branches? Would it needlessly overcomplicated?

sytse 11y ago
You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.
- lgp171188 11y ago
  If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.
  - sytse 11y ago
    Please let me know what you think we should improve to support that workflow better. Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.
    - lgp171188 11y ago
      I have already created a feature request here - http://feedback.gitlab.com/forums/176466-general/suggestions/8483233-support-integration-manager-workflow-which-is-avai http://feedback.gitlab.com/forums/176466-general/suggestions... The main assumption in the Integration-Manager workflow is that code from repositories of other users is always pulled by the owner of the current repository as and when appropriate. So if dev1 and dev2 are working on the same feature in 2 different forks of the main repository, dev1 has to pull commits from dev2 that are needed in his/her fork and dev2 has to do the same in his/her fork. Once the feature is complete, the merge request is created from one of the 2 forks. Yes it is harder to mention issues, but that can be done in the message of the merge commit. Since forks are essentially equivalent to branches in this workflow, I usually don't mind referring to issues in the individual commits itself which would link to the correct issue on getting merged to the main repository. We do this with our team's projects hosted on Bitbucket, ymmv.

nsfyn55 11y ago

I have had this ideological debate about "fast forwarding" more times that I can count. I agree with the author "no-ff" is silly. I've been working on professional software teams for over a decade. When I encountered fast forwarding/rebasing it was absolutely a breath of fresh air. I've been using git now for 5 years and I have not encountered a single instance where using either of these tools has presented any sort of problem. I can't remember a week where having a concise, readable history hasn't proven its value. I also can't remember a single time I've said "Man I'm glad I had all these merge commits around they really saved my proverbial bacon" From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. It gives them something to do between harping on whether your behavior is in the correct "domain", deciding if a list comprehensions are truly "pythonic", and spending that extra month perfecting the event sourcing engine to revolutionize the "contact us" section of your site.

JanezStupar 11y ago
Because you do not need something, then it has to be useless. > From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. Incredible irony.
- nsfyn55 11y ago
  well can you provide the killer use case that none of us can live without? I mean its certainly possible that in some tiny fraction of cases I might say "man I could fix this a lot easier if I had the merge commit" its just in the 10,000's of examples that form my experience I haven't stepped on that particularly landmine yet. Even with that said, my development philosophy compels me to choose "Simplicity over Completeness" and is utilitarian to the core. I will chose whatever is most effective in the vast majority of cases. Some folks look at "Source Control History" as some pristine, historical record of how things went down. Since I am not an accountant or auditor this has little value to me. It encumbers the day to day to optimize for a case that is almost certain to never happen. A first-order approximation of the history that optimizes for the day-to-day needs of an organization is far more suitable in almost every case. I use the term "local team pedant" its not a bad thing. Some folks just have a need for things to be "complete" and feel compelled to do so for irrational(usually expensive) reasons. In my own experience the person that is the "no rebase/ never fast forward" cheerleader can never give a solid objective answer as to what the benefit is. Its usually always something like what this no-ff-er suggests(http://walkingthestack.blogspot.com/2012/05/why-you-should-use-git-merge-no-ff-when.html http://walkingthestack.blogspot.com/2012/05/why-you-should-u...) . Things like "I can see whats on a branch, etc." That in itself is not a justification. Its just words. If you could someone how demonstrate how this reduces development costs or offers a better way to organize work and is simultaneously better than the more idiomatic alternatives then I'm all for it.

jwr 11y ago

That's the first time I heard of GitFlow. People seriously do software development this way? I find that hard to believe. What the author describes is fairly close to what I've been using in a number of companies now for the last 9 years or so. Whether to rebase is a personal preference. I tell developers to always rebase local work before committing. Unobserved changes might as well not exist (if a tree falls in the forest and no one is there to hear it falling, does it make a sound?), so if you haven't pushed your work, rebase it. No one cares when you did the work. As for feature branches, it depends. If the history is clean and there aren't too many at one time, we might merge without rebasing. But I still prefer to clean up the commit history and rebase. I don't understand the obsession with "true history". History is written by victors, in this case — resulting work/code.

dimino 11y ago

I personally find git flow to be a wonderfully elegant and simple way of handling a project in git. Not everything is perfect, but I consider git flow to be much like PEP8. It's almost always a good idea to do it the git flow way, unless you have a very specific and documented exception, in which case do that instead. To me what matters more is the consistency. Also, the attitude and tone of this article straight up stinks.

Finster 11y ago

I can count on zero hands the number of times I've needed to solve a problem by navigating the branch tree. I've lost count of the number of times that two eternal branches and feature branches with pull requests (+ code review) has saved major flaws from getting to production. The develop branch is perfect for automatically deploying our bleeding edge to our test server. Although, if we move to a more continuous deployment approach, we may transition away from two eternal branches. But when GitFlow was first written about, continuous deployment really wasn't the trend that it is now. Methods will continue to evolve...

dankohn1 11y ago

We use a more extreme version of rebasing feature branches before merging into master: we squash the features into a single commit when merging to master. The reason is that we don't care about the (sometimes hundreds of) commits that made up a feature. What matters is that it works as designed and passes tests. If we merge a feature to master and then need to revert it, we will revert the whole feature. This also allows us to keep merging master into feature branches, (where there is only a single commit that might need to be manually merged) instead of rebasing feature branches on master (in which case it can be necessary to manually merge multiple intermediate commits). What cleared up git merge --squash for me was a comment showing that: git checkout master git merge --squash feature is the equivalent of doing: git checkout feature git diff master > feature.patch git checkout master patch -p1 < feature.patch git add .

Thrymr 11y ago
That loses a lot of information, though. If you want to bisect to find a particular bug, tracking it down to the merge is a good start, but I'd rather have the actual commit (from the maybe hundreds) that went into the merge. Sure, you can revert the feature, but what if you want to fix the bug? Git history has a lot of commits. That's OK.
- dankohn1 11y ago
  Yes, the downside of a much more streamlined commit log is that we do throw out information.

jguegant 11y ago

What about using merging when it comes to the feature branches but rebase when pulling (git pull --rebase)? Is it that harmful to rewrite the history for your local changes?

scottious 11y ago

I don't see why there has to be "this is harmful" and "this is a better way". I've used all kinds of branching models... I've used just a master branch and you commit directly to master. I've used full git-flow. I think the branching model you use is dependent on the people and the project. But really no matter which model I've used it seemed to me to be fine... And if it wasn't fine, we extended it to meet our requirements.

jedbrown 11y ago

Git-flow indeed has serious problems. This author is proposing a particular subset of gitworkflows(7). https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html https://www.kernel.org/pub/software/scm/git/docs/gitworkflow... I like subsetting gitworkflows(7) because you can incrementally add process when the tangible benefits (like increased reliability and experimental access for eager users) outweigh their process cost (which depends on team experience). I wrote about these issues here: http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.an... This diagram represents a workflow that uses 'maint', 'master', and 'next' branches. http://59A2.org/files/simplified-gitworkflows7.svg http://59A2.org/files/simplified-gitworkflows7.svg

rdsubhas 11y ago

A single eternal master works for a Continuously Deployed app/site. Not for any other project where maintenance releases are a norm. This includes stuff strict API compatibility projects, semantically versioned frameworks/plugins/libraries, many forms of desktop/offline apps, some android apps, most enterprise apps, etc - more or less where developers don't have the liberty to thrust the latest master on their users. I'm not against CD, and not a big fan of Git Flow either. But different things have their own uses. I'm really liking GitHub Flow and GitLab Flow though!

habitue 11y ago
Right, when you need to maintain (and patch) old versions of a piece of software, having eternal release branches is necessary. The fixes on those old versions often don't ever want to be merged back to master because the code is very different in more recent versions.

nycticorax 11y ago

It seems like one of the ironies of git-flow is that it would actually work better if you used it with Mercurial rather than Git, because Mercurial stores what branch you were on when you made a commit. This means that a tool could automatically look at the Mercurial commit tree and figure out which swimlane each commit belongs in, and use this information to draw a commit history tree that wasn't such a mess. I apologize for the self-promotion, but this answer on Stack Overflow (and the question) talks about this difference between Git and Mercurial, and includes links to articles that explain it better than I could: http://stackoverflow.com/a/26784550/1013442 http://stackoverflow.com/a/26784550/1013442

dicroce 11y ago

Even though I could frequently commit on feature branches, I usually don't. Hence, when I merge feature branches I don't have crazy messy histories that I feel it necessary to rewrite.... Works for me.

songshu 11y ago

I wish GitFlow had not called that branch "master", and had called it "released" or "production" instead. It's really useful to have a branch which you know always exactly represents the code running in production. You can keep an IDE pointed at somewhere and update when you need to without worrying about tags or whatever. This is the one part of it I've tried to sell to colleagues, which would have been easier if it had a better name.

gouggoug 11y ago

GitFlow is also in my opinion a bad flow as it does end up with a merge commit spaghetti over time. Merge commits are great. They are here to group a list of commits into a logical set. This logical set could represent one "feature", but not necessarily. It is up to you to decide whether commits A B C D should or shouldn't be grouped by a merge commit. Merge commits also make regression searchs (i.e. git bisect) a lot faster. And to top it of, they will make your history extremely readable, but that is granted you merge correctly... and that is where git rebase and git merge --no-ff come into play. At my company, every developer must rebase their topical branch on top of the master branch before merging. Once the topical branch is rebased, the merge is done with a --no-ff. With this extremely easy flow, you end up with a linear history, made of a master branch going straight up and only everyonce in a while a merge commit. Our commit history looks like this: *-------------*---------*---------*----------*----*-------> \-----------/ \---------/ \--/ Following the simple rule "commit, commit, commit..., rebase, merge --no-ff" avoided the merge spaghetti a lot of people compain about. Although, I have to admit our repository is small (6583 commits to date). This works even when multiple devs work on the same branch: they must get in touch on a regular basis, rebase the branch they are working on and force push it. Rewritting history of topical branches is only bad if it is not agreed on. As long as it is done in a controlled manner nothing's wrong with it. Another rule we follow is to always "git pull --rebase" (or git config branch.autosetuprebase=true). Our approach might not, however, scale for larger teams or open source projects.

mml 11y ago

Ever since I started getting involved in SCCM stuff, I've been astounded at how much breath and emotion people are eager to waste defending their choice, or technique or strategy or whathaveyou. SCCM system discussions should be banned on HN, as pointless and heated as vi vs. EMACS discussions.

nijiko 11y ago

Do what is easiest for you. 1. Merging vs Rebasing Open source projects should stick with Merging over cherry-picking and rebasing especially if you want others to contribute. Unless you feel fine doing all of the rebasing and cherry-picking for them. Otherwise, good luck gathering a large enough pool of people to contribute. Simplicity always wins here. 2. GitFlow vs X Once again do what is good for your company and the people around you. If you have a lot of developers having multiple branches is actually /beneficial/ as Master is considered ALWAYS working. Develop branch contains things that are ready to ship, and only things that are READY TO SHIP. So if your feature isn't ready yet, it can't go to develop, and it won't hit master. Your features are done in other branches. 3. Rewriting history Never do this. Seriously, it will come to bite you in the ass. 4. Have fun. Arguing is for people who don't get shit done.

orbitur 11y ago

I can distill my thoughts down to this: The time it takes to carefully rebase a branch onto another, and to compress commits for a feature into one, is still much longer than the time it takes for my eyes to pass over so-called "empty" merge commits. If I want to look at when a feature entered a branch, I can look at its merge commit. And the feature branches are there to show how a feature was built; bugs could be the result of a design decision that happened in one of the midway commits. I looked at OP's example pic in the blog, and I read all of his words, but I wasn't sold. His picture looks like a normal git history to me. It requires almost no effort to find what I'm looking for. And that's not even touching his rage against the idea of a canonical release branch (master). But that's for another day.

5outh 11y ago

On the main project I'm working on, the reason we have develop/master is mainly for hotfixes. We deploy once a week, but if we need to get something out the door quickly, we make a hotfix branch off of master, then merge it into both develop and master. This way, if we find something that needs to be fixed before the next release, but don't want to push half-done updates, we can seamlessly do it.

mcv 11y ago

Advising rebasing over explicit merges is dangerous and foolish. Rebasing does have its place, but you really need to know what you're doing. Also, I don't see his point about that messy history. I can see exactly what happened in that history (though the branch names could have been more informative). With multiple people working on the same project, feature branches will save your sanity when you need to do a release, and one feature turns out to not be ready.

juandazapata 11y ago

It's not confusing, maybe it's not suited for your particular case, as any other tool. There's no magic tool/process/etc that does it all for everybody. GitFlow has been working great for us. A team of 15 developers, working with feature branches, we have our CircleCI configured to automatically deploy the "develop" branch to our "QA environment", and our "master" branch to "production" environment. The "hotfix" and "release" are proven to be useful to us too; we just need to have effective communication with our team, so everybody rebase their feature branch after a merge in our main branches.

JulianMorrison 11y ago

The whole point of hotfixes is that they are relative to old code and that they alter what is considered the current version of that old release. Which is important when (as is typical in business) you have customers who are on specific releases and either haven't paid for the new hotness, or haven't integrated to it and don't yet want it. So absolute minimum you need one persistent branch per old release, if you ever hotfixed it and still have it deployed in the field. GitFlow falls over here, because it only has one master. But at least it does recognize the fact that repairing released code is different from pushing the unreleased state of the art forward.