-2

I'm hoping someone can point me toward a workflow that will make sense for our setup, because sorting through all the conflicting information online has proven somewhat useless.

We have been using a modified version of the "GitFlow" workflow for the past few months. These are the permanent branches we have:

  • master (contains production-ready code)
  • beta (contains the latest "demo" for the client)
  • develop (contains the latest work for the project)

As you can see, our workflow differs from the traditional GitFlow in that we have a beta branch in addition to develop. As such, we often have to include individual features (from feature branches) in beta without merging in the entirety of develop. This is where our problems arise.

When we create a feature branch from develop, it is synced with develop frequently. This means that when we try to merge in a feature to beta, it includes tons of unwanted commits that happened on develop.

The only "solution" we've been able to find is to manually recommit (or cherry-pick) changes from feature branches into beta. This is very counterintuitive and I know there has to be a better way.

Another problem is that when we need to create a hotfix for the entire project (to be applied to all branches), we create it from master, and it won't merge into develop without an insane amount of merge conflicts. This could also be done via cherry-picking, but we absolutely need our workflow to be accomplished 100% using the GitHub desktop app and website. I'm familiar with the command line but I've been given explicit instructions that we can't rely on it.

One option I've considered is to try a rebase-centric workflow rather than a merge-based one, but this is problematic as rebasing isn't nearly as simple as merging (and I don't even think it's possible to do without the command line).

Please help!! There has to be a simple way to do this and we're just not seeing it.

Keith Pickering
  • 696
  • 10
  • 24
  • So you can rely on the GitHub UI, which GH can change whenever they feel like, but not the *actual Git CLI?* Have you considered quitting? – jonrsharpe Feb 26 '17 at 16:44
  • No, but thank you for posting this as a comment and not an answer because it's not even remotely helpful. – Keith Pickering Feb 26 '17 at 16:53
  • 1
    You're trying to solve an organisational problem with a git branching model, and have your hands tied on the tooling. It's worth knowing when you are likely to succeed. – jonrsharpe Feb 26 '17 at 16:55
  • The project manager who tests our updates simply doesn't want to use the command line. I don't like using it either; I'm a frontend developer and I always prefer GUIs. I don't see how this is an outrageous request. GitHub can change the UI at any time, sure, but they obviously won't update it to make it any *less* useful. Requiring everyone to learn the command line would take so much extra time that it would make more sense for me to just keep cherry-picking for everybody. – Keith Pickering Feb 26 '17 at 16:57
  • I should note that we can potentially use *any* GUI, free or paid. I know there are ones that can do more than the GitHub solution, I just need to figure out the proper workflow before anything else. – Keith Pickering Feb 26 '17 at 16:59
  • 3
    Now you're getting somewhere, these are the actual problems. Why does the PM have to care about the VCS? In my current project, for example, our CI deploys tested code to an environment where the PM can play with it; she doesn't have to care where the code lives, much less how to check it out and deploy it herself. A git branching workflow is rarely a good solution to any problem. Move to [softwareengineering.se] and give more useful context. – jonrsharpe Feb 26 '17 at 16:59
  • I couldn't tell you, but it's not really up to me. If I can figure out a workflow that I can be 100% sure will work, then I can consider proposing a change to how we deploy and test code - but if it can be done with any git GUI, that would be preferable. – Keith Pickering Feb 26 '17 at 17:03
  • I agree that's a poorly thought-out restriction. If it must be through a GUI then how about an IDE? Many provide more features and are hands-down superior to the app (Intellij for one). – ChiefTwoPencils Feb 26 '17 at 17:04
  • "A git branching workflow is rarely a good solution" What is, then? Merging is one giant headache. If we could do what I described in the OP without anyone needing to merge branches, I'd love that. I just don't see how it's possible. – Keith Pickering Feb 26 '17 at 17:07
  • @ChiefTwoPencils Any GUI would work as long as it's easy enough to understand. I just need to figure out the workflow itself. If the PM were to relinquish his task of testing+merging feature branches, that job would likely go to me, and I'm not comfortable with that unless I'm 100% certain we have a solid workflow planned. – Keith Pickering Feb 26 '17 at 17:09
  • By the way, I am really mystified why both the question and the sole answer so far got downvoted. It is a perfectly valid question; it is not uncomprehensible or showing lack of research of the OP. While I appreciate that many people do not know anything else than GitFlow, it is very enlightening to be aware that GitFlow is not something special. It was not created/documented by the inventors of git, and certainly has no special status that makes thinking about other branching workflows somehow bad. – AnoE Feb 26 '17 at 20:12
  • It's just like Reddit - give people the opportunity to "downvote" something and they'll do it as long as they already see a negative number. Some kind of power trip, I'm guessing. These sites will never work the way they're meant to until good answers are determined through positive actions rather than negative ones. – Keith Pickering Feb 27 '17 at 14:51

2 Answers2

0

Yes, you can use TortoiseGit as the GUI or others, the operations are similar.

  1. Put changes of feature branch to beta branch:

TortoiseGit -> create patch serial -> select feature for Since -> choose 1 for Number Commits (If you want only the latest commit is applied on bate branch) -> OK

-> TortoiseGit -> Switch/Checkout -> beta ->ok

-> TortoiseGit -> apply patch serial -> add the patch you just created -> Apply.

Now only the latest commit from feature branch is applied on beta branch.

  1. For the problem of applying changes from hotfix branch to develop, you can also use the above way of creating/applying patch serial.
Marina Liu
  • 36,876
  • 5
  • 61
  • 74
-1

Enter Dymitruk

You are looking for "Branch per Feature" by Adam Dymitruk http://dymitruk.com/blog/2012/02/05/branch-per-feature/ . It is exactly what you are asking for.

It has a different twist on things than GitFlow; it uses 3 main types of branches: master, Feature branches, and a qa branch. The latter is like your beta branch.

master is the version that is on your production servers right now. All other branches go off of this one.

Feature branches are just that. They always branch off of master (which is the main difference to GitFlow).

qa is per definition the "next" version that will be going live on the production server.

It uses heavy rebasing, together with the rerere cache of git, which avoids doing conflict resolution over and over again.

Feature branches are never merged "back" into some kind of develop branch (there is none). Instead, at any point where you have a set of feature branches that are ready for testing, qa is recreated from scratch, starting off of master, and having the "ready" feature branches merged into it. No branch starts off of qa, and you never commit anything into qa. You also never re-merge changes from a feature into qa, you always start it from scratch.

This sounds like a conflict nightmare, but is actually very simple. Due to the rerere cache, usually, only "necessary" conflicts occur. Every conflict that ever happened once, is then automatically resolved by git on its own. This operation is of course automated with a relatively simple shell script.

As a side effect with huge benefits, is is trivial to back features out of qa at any point (simply rebuild qa, leaving out the feature).

This means that when we try to merge in a feature to beta, it includes tons of unwanted commits that happened on develop.

With Dymitruk, beta (a.k.a. qa) starts off of master, merging all features that are ready for testing into it.

Another problem is that when we need to create a hotfix for the entire project (to be applied to all branches), we create it from master, and it won't merge into develop without an insane amount of merge conflicts

With Dymitruk, hotfixes go into master (of course, as master reflects the production server). Then, all feature branches are rebased upon the new master, and finally, qa is created from scratch, starting at the new master.

rebasing isn't nearly as simple as merging (and I don't even think it's possible to do without the command line).

Rebase is, in this scenario, actually simpler than merging for the very reason that rebasing applies one commit after the other, hence works on smaller units of work. Merging, instead, subsumes all commits that happened on the branches. This means that as soon as the rerere cache enters the game, git will be able to solve most conflicts on its own.

Obviously, if someone decides to change all spaces to tabs in all your code files and starts committing such a change to master, then you're borked. But that's no different from merging, at all; the problem just occurs at a different point of time.

As you only ever rebase feature branches, you only really get the usual rebase problem when more than one developer works on a specific feature branch at a time. You can either avoid that, by making feature branches small enough. Alternatively, you'll have to communicate between developers. But in the end, if people are aware what they are doing, then a distributed rebase is surely possible. If in doubt, you can use heavy tagging as a backup measure, to avoid actually losing anything; but you will find after a while that it really is a non-issue.

Addendum

From the comments:

Suppose somebody is working on a feature branch and they need code from another in-progress feature (this happens very often).

You can start a feature branch off of another feature branch instead of master.

Of course, then you have to pay a bit attention; if the parent feature branch gets more commits, you want to rebase the child on it. If master changes, you have to make sure you rebase the parent feature first, and then rebase the child on the parent, not on master.

Regarding the qa, nothing changes.

As you will be using scripts for the two major operations (remaking qa, rebasing all features), it's just a matter of keeping track of this in these scripts (which does not need any additional storage or configuration; these case can rather easily be deducted with basic git branch --list commands.

Also, is there any way to accomplish this workflow using a GUI?

You will want to have at least the (re)creation of qa and the rebase processed scripted. Since there will be regular conflict resolutions during these, they need developer attention, and thus are probably best done by command line scripts. Of course, you can use your usual preferred git GUI for merge/rebase conflict resolution; behind the scenes, it's all just git as usual.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • This sounds really promising, thank you! Suppose somebody is working on a feature branch and they need code from another in-progress feature (this happens very often). What would be the best way to go about that? I've tried to get our developers to use cherry-picking but I'm not sure if they really get it. – Keith Pickering Feb 26 '17 at 19:22
  • Also, is there any way to accomplish this workflow using a GUI? – Keith Pickering Feb 26 '17 at 19:27