git branch per ticket

[David Schwartz]

We use Jira and an in-house ticketing system to track requests from customers. We have a somewhat unique development situation and I'm curious if anybody has any recommendations to help us use git better.

We service clients on a long-term basis. We host various services and for the most part clients upload data via FTP and it gets processed. The processing is done, in part, using an app that's custom built to import their data into our system. Everything past that point is standardized. 

From time to time they need us to update some details that relate to their upcoming data processing needs. They contact a customer svc rep (CSR) and they create a Jira ticket and we devs pick them up and work on them. Most of our customers are resellers, and they have multiple clients on behalf of whom they do stuff. 

The tickets we get can take from one hour to one day to a week or so to complete. It's typical that one person will handle the entire ticket. The nature of the work is such that we modify some files, compile stuff, run it, and produce "proofs" for review by CSRs and the customer.

We maintain a folder with dev files in it for each customer. Some have things set up to manage all of their clients in that one folder. Historically speaking, some devs have set up customers with lots of clients so each client has their own folder independent of the others. This isn't common, but it exists. All of these folders are in a single virtual drive that is where the git repo is located. There are about 850 of them, but we only have 100 or so active.

When a ticket lands on my desk, I find the folder where I need to do the work, I create a branch for that ticket, then I start work. In a perfect world, I'll finish that ticket completely before I start the next one. In reality, that does not happen. Most of the time we overlap work on tickets, in part because even if our work takes only an hour, it might take 3 days to hear back from the customer if the proofs are deemed "acceptable" or not. Most of the time they are.

Historically speaking, the dev is not expected to do a commit or push until the customer has approved the work. 

However, this flies in the face of people who advocate to "commit soon and commit often". What happens when we do that is a slowly growing mess of conflicts because changes are not isolated by branch or folder. People tell me that's what SHOULD be happening, but it's not.

When we get approval, we commit the changes, then we push to master. I don't think we're doing something right because we have to deal with conflicts from time to time that are of no concern to us. 

We have no core dev, QA, or release branch. What's in "master" is what's in our "production" facility. If production servers crash, the theory is we can replicate what's in "master" and everything is up-to-date. Everything else is WIP.

The only other tricky part is that some of our customers have multiple clients, and we can get several tickets for different clients at the same time. We need to overlap the work, but in reality, we're modifying the same four files in different places for each client. So just using separate tickets will inevitably cause merge conflicts when we have 9 tickets that all require updates to the same four files in the same week. 

All of these fancy "gitflow" and "three-flow" and other approaches simply don't work for us. We have quick-turnaround work driven by a ticket. There's no "core product", but one product per customer or individual client, all in separate folders in one repo.

I realize this is a long-winded explanation, but I'm trying to see if anybody has any ideas in terms of how to make this work in git that may be different from what we're doing. What are the git statements you'd use to: (1) start work on a new ticket; (2) interrupt your work for the day or to send proofs out for review and approval; (3) resume work; and (4) after getting approval from the client, wrapping everything up.

(We have our own internal jira and git servers as everything is locked inside a highly-secured work environment.)