Problem with git management
Posted by Flame_Horizon@reddit | ExperiencedDevs | View on Reddit | 42 comments
I’m working in a team, where we have developer and a dedicated person (not developer, sort of “release guy”) whos sole work is to manage releases on PROD and UAT envs. One thing which hurts developers is that he is the one who takes our features branches and merges them to dev branch which is a very slow process on our case.
This slowness also affects me. In my case, let’s say I have request to create feature A and feature B. 90% of changes in the code does not affect both A and B at the same branch. But that last 10% would affect both. Let’s say I start working on feature A and edit some startup code (ASP.NET). This change would change behaviour of the application and that change is also required in feature B.
What I would do normally, is to complete feature A, merge with dev branch and pull these changes into feature B. Which for me personally is very short dev loop. But because it takes weeks to merge towards develop. My work in B is halted.
How to overcome such case where I still can work on feature B without waiting for that merge to dev? Should I adapt somehow workflow of my work? I’m at boiling point and looking for any solution.
retirement_savings@reddit
My org at Google doesn't do branching at all and I'm glad to not have to deal with issues like this anymore lol. Everything is developed at head, and you use feature flags to gate code that isn't prod ready yet.
arstarsta@reddit
Are you using gerrit?
retirement_savings@reddit
No, Fig + Cider
saposapot@reddit
You don’t do PRs? How you do ensure code reviews?
retirement_savings@reddit
We have PRs. They just go straight to head, not a feature branch.
edgmnt_net@reddit
It's less of a problem if PRs don't take a long time to merge. Because your topmost feature work won't get stale waiting for dependencies in other PRs.
However I'll say that naive use of PRs (i.e. treating PRs as changes despite not being native Git history concepts) can still cause delays, cause bad history or at the very least require otherwise unnecessary tooling if you end up stacking PRs instead of stacking commits in a PR. More involved work may require multiple separate commits to ease reviewing and bisectability.
binkstagram@reddit
I'm now curious as to how you have you ended up in a position where it takes a full time job to manage releases. I've not experienced anything like that across multiple workplaces. Release guy must be slowly losing his mind with boredom?
Why aren't individual devs merging to the dev branch?
FireArachna@reddit
Why is he the one to merge into dev branch? If he only cares about PROD and UAT, dev branch should be fine for devs to handle, right?
Flame_Horizon@reddit (OP)
Yes - I would think so dev is for developers to have place where we all push changes to after review. Then create a tag or release branch from which release people can take code and deploy it to UAT env (Jenkins can do that).
This is not the process, I’ve tried to query about that but got only murky explanations with many “what if x happens” where that x happened 2 times in last 3 years.
Sensitive-Salary-756@reddit
Im a bit confused OP. Are they QA/release manager that needs to attest whether the software is fit for release to the customer or not?
If this is not the case, why does this process need to be there in the first place? Couldn’t the code be auto deployed once it pases unit/integration tests (and maybe a separate staging or QA area if needed)
Flame_Horizon@reddit (OP)
This person is not QA. We do have dedicated person for manual testing and we do code review per PR. From my pov, the resposibile for taking out code from feature branch and merging that into what ever branch that person want for the UAT release (it isn’t always dev lol).
The reason I’ve heard way once a year, there is an audit done, and that audit requires that developer should not be responsible for deploying code onto any env. Because of that, we write code, test it locally, push to feature branch, do peer review and once it is ok - we don’t control code any more.
gUI5zWtktIgPMdATXPAM@reddit
Why is that? Generally developers have a Developer environment which is for.. developers. I can understand any higher environments needing approval, usually testers decide what goes into UAT etc and production well that's the product owner.
Flame_Horizon@reddit (OP)
I can’t answer this “why” question, but I can agree with your view and I share it.
HoratioWobble@reddit
You can create Feature branch B from Feature A directly, you don't need to merge it in
edgmnt_net@reddit
Or just make one single PR and have commits reviewed individually. This is actually the standard way in many classic open source projects. Totally reasonable if the work isn't being kept back from being merged for too long and, in OP's case, it looks like merging takes a long time anyway.
saposapot@reddit
What do you mean commits reviewed individually? If you don’t do a PR then you don’t get that nice UI for reviews and all that…
edgmnt_net@reddit
You submit a PR as usual, just with relevant commits inside and nicely cleaned up. However, reviewers don't just look at the overall diff but also inspect each commit and leave comments/approvals (on the PR at the very least, if not individual commits).
At a first approximation, you can introduce common stuff in a commit, then feature A in another commit and feature B in another commit, so they can be reviewed on their own. Dependence is softly implied by the order of the commits, there's no way to accidentally merge just one of the commits.
Whether this can be automated and enforced nicely in your org is a different thing and it's entirely dependent upon what the Git host offers. But overall this has to work because it's fairly standard workflow in open source. It usually works alright on its own with typical stuff like GitHub and BitBucket if people can be bothered to look at the commits view and per-commit diffs.
(Compared to the old email workflow, a PR is pretty much like a patch series.)
HoratioWobble@reddit
This muddies the water for related but distinct features.
saposapot@reddit
This is it. Obviously the main problem should and needs to be solved but for you the only fix is this.
The drawback is that you are commiting to the project timeline of A being merged then B. If A is rejected or delayed then B is blocked by it also.
So there’s clear problems with this approach. You really need to solve the main problem, otherwise it always gonna be a pain.
If you want to get highly perfectionist what you should do is a “before A” branch where the common needed things are put there with high priority for the merging. But that is a bit of dream where you can really sit down and think about features in A and B and see what’s common and should be shared.
I have this a lot since the project is monolith with BE and FE devs working together in a feature. We both work on the same feature branch or we have a “parent feature branch” for the shared stuff.
What we do to optimize is actually do small changes/releases behind feature flags. So if the feature needs to have a create/edit/view/delete we split that into 4 releases so each is small enough to keep things moving along.
We need to assume the “timeline” but since this is a clear timeline that we want, it’s fine. And it’s all behind feature flag that is only turned on when all is done so any change is fine to do.
Being smaller the work of the gatekeeper should also be easier and merging more stuff per day.
briznady@reddit
And if you don’t push feature branch B, you can rebase it onto dev, so that only the commits since it branched off of feature branch A are included in the PR.
cooking-chef-2000@reddit
I generally try to avoid this. Is this actually more common that I originally thought?
HoratioWobble@reddit
I'm a contractor so end up in different work environments every 6-12 months and when the company insists on doing PRs, it's been the only way I've found to solve slow reviews / merges.
You can either sit and wait, work on something completely unrelated or create a stacked branch.
Git handles the history anyway, unless you squash and merge then it becomes a pain.
gyroda@reddit
We do this at work.
I've been told that the solution here is rebasing, but I never got around to learning to do it properly and always make a pigs ear of it.
Flame_Horizon@reddit (OP)
You say, stacked branches. Right?
HoratioWobble@reddit
Yup
loosed-moose@reddit
GH is (was?) doing a beta for stacked PRs that automatically stack in the UI if they're daisy-chained in this way
HoratioWobble@reddit
Not sure, I've never really paid attention to the UI it's just been the most sensible approach I could find to the problem
turturtles@reddit
It was more of a blog post type announcement where they said select customers would be invited, if I remember correctly
BusEquivalent9605@reddit
we keep having these sorts of issues
i keep saying “Feauture Branches” (wherein we have a base feature branch any number of devs can branch from)
my team keeps being like “but we dont wannna”
and then a month later “how can we fix this bottleneck”
me: 🤦♂️
saposapot@reddit
Why is he the one merging feature branches to dev?
Also releases is one thing, merging to dev branch is another.
You create a PR from a feature branch to dev and when everything is approved, it’s merged to dev.
The release is a different thing. If he only wants to release on fridays then he takes dev on fridays and does the release. If he wants to release for each merge to dev, then he can. That’s a different decision altogether…
It can also help to introduce feature flags and code things behind them. Then you can even, in theory, have continuous deployment from the dev branch and a “release” is more about turning the feature flag ON than a real code release.
I work a bit differently but we also have devops guys but they aren’t in charge of merging feature branch to dev. That’s done after a PR gets approved by 2 other devs. Or specific approvers. Devops only works with dev branch that they take into PROD when a release is ready
MatterHoliday3769@reddit
Make new branch off main dev, merge A it, continue work on B. When you do the PR for B after he accepts A it would read the same, as long as you rebase before submitting PR for B.
Or work on feature C until you are comfortable working more on B.
SpiderHack@reddit
Avoid rebasing at all costs. Destructive operations to make a graph look pretty are pointless. Just merge the changes from develop/main (whatever your main branch is) into your branch and move forward. No reason to pretend your work happened in the past, etc. (I know this hurts some emo soul somewhere, but that just makes it more correct ;)
loosed-moose@reddit
Learn more about version control so you're not so afraid to rebase. It's not just useful for "pretty graphs"
gUI5zWtktIgPMdATXPAM@reddit
It's useful to be able to follow history and what was done. It helps you clean that history up.
Xydan@reddit
Sounds like you're treating dev as a trunk. We solved this by creating a release branch which acts as a secondary trunk where deployments begin. This left dev completely up to the lead/head software manager to manage rather than the lead/head release manger
cap87_@reddit
Since you're not doing trunk based development, why not simply read about gitflow, testing it yourself and teaching the team how to do it properly?
farzad_meow@reddit
use rebase and let actual dev be responsible for merging. now this person needs to be retrained on something else, either work as another developer, or switch to full qa. be careful how you bring this to your manager.
SheriffRoscoe@reddit
Your problem is that the developers are moving too much faster than their consumers. If you were doing Kanban, this world stand out like a shoe thumb - you'd have developers blocked from starting their next task because their previous task was not yet handed off.
You need more downstream capacity.
Traditional_Fox7091@reddit
Can have a dev branch which is different to release branch. Otherwise base branch b of branch a but that’s not ideal
Flame_Horizon@reddit (OP)
I think we could have something like that. Am I getting you right. Main (prod) > dev (uat) > pineapple (developer’s branch) > feature branches. Right?
Traditional_Fox7091@reddit
assuming when u merge into pineapple ur work is done right? You don’t have to work off dev or main. You can create branch b off pineapple. It will have ur changes from branch a and all the other devs changes too
MsCardeno@reddit
Git work trees can help you here.