convore.json/groups/git/best-way-to-merge-in-changes-to-a-long-running-branch/messages.json

[{"user_id": 13326, "stars": [], "topic_id": 17975, "date_created": 1302223094.286257, "message": "Is it true that it is bad in the long-term to merge in master from your branch as opposed to rebasing? And if so, what's the best way to handle this?", "group_id": 106, "id": 582751}, {"user_id": 8391, "stars": [], "topic_id": 17975, "date_created": 1302223520.226872, "message": "http://nvie.com/posts/a-successful-git-branching-model/", "group_id": 106, "id": 582807}, {"user_id": 8391, "stars": [], "topic_id": 17975, "date_created": 1302223524.142247, "message": "it's absolutely worth reading.", "group_id": 106, "id": 582809}, {"user_id": 8391, "stars": [{"date_created": 1302271728.4424429, "user_id": 2320}], "topic_id": 17975, "date_created": 1302223508.512758, "message": "I recommend using this git workflow", "group_id": 106, "id": 582806}, {"user_id": 5794, "stars": [], "topic_id": 17975, "date_created": 1302228681.8737099, "message": "Dang. Though I was doing alright. Now I'm going to go and recreate my work on the 1.1 branch to use the --no-ff.", "group_id": 106, "id": 583850}, {"user_id": 8391, "stars": [{"date_created": 1302334490.037075, "user_id": 19566}], "topic_id": 17975, "date_created": 1302229974.479877, "message": "See also: an awesome tool for managing it all: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/", "group_id": 106, "id": 584238}, {"user_id": 1736, "stars": [], "topic_id": 17975, "date_created": 1302238841.55599, "message": "We have had trouble with their use of master for all release branches, easier to maintain distinct, long-term branches.", "group_id": 106, "id": 586553}, {"user_id": 2320, "stars": [], "topic_id": 17975, "date_created": 1302271723.4184301, "message": "+1 for git-flow, there's a script to help as well https://github.com/nvie/gitflow", "group_id": 106, "id": 590241}, {"user_id": 1822, "stars": [], "topic_id": 17975, "date_created": 1302280450.041327, "message": "I really like the design the approach of git flow, but I haven't been able to use it much - because in collaborative OSS work, the whole project must adopt it all or nothing, and it becomes another participation hurdle for contributors.", "group_id": 106, "id": 592439}, {"user_id": 1736, "stars": [], "topic_id": 17975, "date_created": 1302286121.650553, "message": "@ptone That depends, for local feature branches you can use it yourself without bothering others.", "group_id": 106, "id": 593758}, {"user_id": 15141, "stars": [], "topic_id": 17975, "date_created": 1302619539.783637, "message": "+1 for git-flow. I use git-flow with a friend and it works perfectly for large projects. @ptone you don't have to force other to use it, but I believe it is a very good practice to defend. In fact, I believe locally it is better not use it and use the git-flow paradigm to \"communicate\" with others.", "group_id": 106, "id": 643456}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302629417.626183, "message": "@ptone Can you elaborate on why you believe \"the whole project must adopt it all or nothing\"?", "group_id": 106, "id": 646144}, {"user_id": 8327, "stars": [], "topic_id": 17975, "date_created": 1302634143.935456, "message": "@unbracketed Assuming all developers are equal, if one starts committing straight to master, or poisoning the develop branch with partial feature commits, then the entire point of git flow is defeated, not just for them, but for the project as a whole.", "group_id": 106, "id": 647541}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302634461.1567459, "message": "(I'm not advocating for or against, was just curious because we have some people using it, some not mixed across multiple projects and it hasn't been a problem)", "group_id": 106, "id": 647573}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302634384.18223, "message": "I see - so you feel that git flow makes it more likely that developers will not follow the branching protocol?", "group_id": 106, "id": 647563}, {"user_id": 2320, "stars": [], "topic_id": 17975, "date_created": 1302649579.5981641, "message": "@mal can't that be said for any scheme?  I don't think git-flow is more prone or vulnerable than any other methods.", "group_id": 106, "id": 652435}, {"user_id": 8327, "stars": [], "topic_id": 17975, "date_created": 1302663812.5339191, "message": "@unbracketed I don't think it makes it more likely, but I feel that if it happens, it defeats the point of using it at a project level (as many as want can still use it at a local level)\n@catsby it can, and it's not, no dispute here", "group_id": 106, "id": 656062}, {"user_id": 1822, "stars": [], "topic_id": 17975, "date_created": 1302668658.9693501, "message": "@unbracketed if a project's main repo doesn't at least adopt the conventions of a develop branch, and release branches, then git-flow isn't really in play.  Git flow is all about conventions, so unless those are adopted, then we are just talking some hybrid git workflow involving a assorted branches.", "group_id": 106, "id": 657596}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302674119.5019419, "message": "@ptone @mal Thanks for the perspective. Would you guys recommend git-flow to git newbies? Personally I've become hesitant to because I think understanding the mechanics (and flexibility) of branching and merging in git is one of the most important factors for using it successfully.", "group_id": 106, "id": 659732}, {"user_id": 960, "stars": [], "topic_id": 17975, "date_created": 1302702262.7562571, "message": "@unbracketed I wouldn't do it.  I personally think git-flow is adding process to branches under a different idea of what a branch is.  Use Git first.  Play with some different workflows and find something that works for you.", "group_id": 106, "id": 665143}, {"user_id": 960, "stars": [], "topic_id": 17975, "date_created": 1302702316.6005809, "message": "@unbracketed It may be that git-flow does work for you, but make sure you understand the basic flow of Git and its understand of branches before you automatically assume that someone else got it right.", "group_id": 106, "id": 665153}, {"user_id": 1822, "stars": [{"date_created": 1306579447.084008, "user_id": 31883}], "topic_id": 17975, "date_created": 1302702591.732785, "message": "@unbracketed I think in the controlled setting of a closed team - git-flow would be great for beginners because it gives lots of context for how to use git branches. @tswicegood I think you still learn basic feature branches, but you get a better idea of how they fit into a product release cycle and what kind of changes go onto which branches.", "group_id": 106, "id": 665191}, {"user_id": 2320, "stars": [], "topic_id": 17975, "date_created": 1302701710.353966, "message": "@unbracketed I wouldn't, for those same reasons. It's best to know what's going on and how to do those things manually first, IMO", "group_id": 106, "id": 665048}, {"user_id": 1822, "stars": [], "topic_id": 17975, "date_created": 1302702784.702955, "message": "however per my original comment, I don't think it is good for open teams, because you are constantly trying to LOWER the barrier of participation and get new people to help out.  If you make the required stack more complex than it has to be, you will lose potential contributors.  Things like \"we don't use make for builds, we use crazy-pumpernckle build-tool, which requires you to download a new compiler blah blah\"  etc.  If you have in your contributor docs \"we use git-flow for managing releases - it means that a potential contributor who doesn't know it will feel they have to learn \"one more thing\" to pitch in", "group_id": 106, "id": 665216}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302707730.670934, "message": "(with the understanding of course that if I have access to push branches and push one that doesn't follow the naming scheme other users relying entirely on git-flow would be \"excluded\" from that branch)", "group_id": 106, "id": 666109}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302707296.435972, "message": "@ptone I get what you're saying, but I don't see any reason one couldn't follow git-flow compatible branch naming schemes for the repo (which is just using consistent prefixes for the various branch types) and let the end user decide whether they want to use the tool or not. Similarly, if you created a repo with (or even some time later decided to adopt) the git-flow branching conventions, I still don't have to use git-flow to work with your repo.", "group_id": 106, "id": 666021}, {"user_id": 1822, "stars": [], "topic_id": 17975, "date_created": 1302721097.02917, "message": "OK - I guess I'm talking more about the conventions of the pattern, and you are talking more about the tool, in which case think we are talking about somewhat different things and agree more than disagree", "group_id": 106, "id": 669665}, {"user_id": 2588, "stars": [], "topic_id": 17975, "date_created": 1302722607.650636, "message": "@ptone Yep, I'm not trying to be (too) pedantic, just pointing out that any end-user tool - whether that be git CLI, git-flow, some GUI, etc. - won't prevent a user from not following the agreed upon branching protocol.  On the other side of the coin, I can publish repos containing branches that follow the git-flow branching model without ever using git-flow on my end. Likewise you can consume and work with those repos using tools of your choice - which may not be git-flow. So the main point I disagreed on was the notion that end-users would be \"forced\" to use git-flow if you had chosen that as your branching model.", "group_id": 106, "id": 670144}, {"user_id": 8327, "stars": [], "topic_id": 17975, "date_created": 1302723925.980026, "message": "@ptone @unbracketed This conversation suddenly makes more sense! I too was thinking more in terms of convention rather than the tool itself.", "group_id": 106, "id": 670459}, {"user_id": 8327, "stars": [], "topic_id": 17975, "date_created": 1302724039.2878931, "message": "I'm currently in the process of introducing git, and the git flow conventions to a small close team at work, the tool isn't of particular use here, as my coworkers almost exclusively use Windows and gui interfaces (IntelliJ plugins and SmartGit), so it's been much more of a issue of training them in the convention rather than the tool itself.", "group_id": 106, "id": 670495}, {"user_id": 8327, "stars": [{"date_created": 1302729371.5175681, "user_id": 2588}, {"date_created": 1306625029.600683, "user_id": 960}], "topic_id": 17975, "date_created": 1302724202.7652371, "message": "That goes some way to answering @unbracketed's guestion about using with git newbies; I feel learning the tool ought to be secondary to learning the process, otherwise you end up with guys that can happily use git flow, but can't use git without it. Similar to the jQuery vs Javascript discussions I've seen a rise in lately.", "group_id": 106, "id": 670521}, {"user_id": 2588, "stars": [{"date_created": 1306625038.453759, "user_id": 960}], "topic_id": 17975, "date_created": 1302729447.8236439, "message": "Regardless of the setting, I'm definitely more comfortable with people using git-flow when I know they already understand what the actual git operations are going to be.", "group_id": 106, "id": 672051}, {"user_id": 3647, "stars": [], "topic_id": 17975, "date_created": 1306521851.7272029, "message": "Regarding the original question and git-flow. If we have a bunch of feature branches that are complete but will be launched in v2.0 and we are still working on v1.X branches... Would these v2.0 branches be sitting there in limbo until it is time to merge v2.0 into dev? Or would it be better to create a v2.0 branch and manually merge in v2.0 branches? Or is there a better way with git-flow?", "group_id": 106, "id": 1207854}, {"user_id": 3647, "stars": [], "topic_id": 17975, "date_created": 1306522410.2674, "message": "Is this a case for a long running release branch? How would that work?", "group_id": 106, "id": 1207936}, {"user_id": 8327, "stars": [], "topic_id": 17975, "date_created": 1306719927.42959, "message": "I don't believe git-flow (tool or convention) caters for this explicitly, however there's nothing to say you can't fork \"develop\", but obviously the tool wouldn't necessarily cater for merging features into it, or basing a release on it, and you'd have to take care of these operations manually.", "group_id": 106, "id": 1222781}]