Staging -> main
Let's say I have a staging branch that I squash & merge into main.
Now when I go to work on the staging branch again, it will have all the 'loose / unsquashed' commits from main. What's a good workflow for this? I'm currently deleting my local and remote staging and then checking out with the main's new commit history but that feels really shitty.
21 Replies
Does
git rebase main work?
I don't know if i agree with this strategy though. Why are you squashing? Rewriting the commit history like this constantly on your hot branches doesn't feel very "git"y
If you just want markers for where one production version was pushed, you can use git tags
Squashing commits like that also makes you lose detailed information about what happened in the deployment
Squashing is usually only used when merging a feature branch. That branch is deleted afterwards. It lets you work on a feature branch with ugly commit messages like
- did work
- backup for today
- switching to laptop
- final version
... and then once you're done and ready to merge, you can turn the 4 ugly commits into nice and commitYeah, working on staging is the anti pattern here
Yeah usually you have a setup like this i think
main <- staging <- dev <- feature branches
I never worked with it myself though, at least not with a staging branch
Yup, that's how we did it at my last job
I'm curious. Did you guys hae some sort of tooling in place to manage these branches or did some poor person have to hammer git commands all day?
Once dev is in a potentially release state, you merge it and create a tag, then check it out onto your testing or staging environment.
We protected the main branch, and merged into it with pull requests
But there were only two of us so it wasn't really that much of a hassle
We used gitlab
I did main dev feature myself once on a one man project and it was a big mistake lol
I just did it because my deployment was auto triggered on push to main. Later switched it to deploy on tag push which let me get rid of the dev branch
That's smart about git tags, didn't think about those. Yea, staging is effectively our dev branch, and then main is UAT / prod. The reason why we separated the 2 was because we wanted to have a clear indication of what is in prod
I don't think a rebase would work since I believe it would pull in all the extra loose commits, so realistically I think we just don't squash
Which sucks because the history might have a lot of wip commits or whatever but it is what it is. It's better for the workflow than adding a new feature branch since we're just trying to push things out atm, and because staging is our dev env
yeah, the solution for that would be to squash from feature branches
when we added a feature, we would checkout a new branch named for the ticket that described the feature, then squashed before we merged with the dev branch (if we felt like it / there were a lot of commits)
lots of git hosts will even let you specify you want to open a new branch for a ticket, which can be helpful, though creating a branch is also super simple
Yea that's what we were doing before, but because we were trying to push consistently (multiple commits a day between the two of us), and everyone's commits relied on each other since it was between 1 or 2 files, we just decided to work on one branch and tell each other when we pushed lol
I think since we're not at that stage anymore with this feature we could probably reintroduce feature branches now that I'm thinking about it
that's an entirely valid strategy once a project goes into a more feature complete or maintenance phase yeah
So I guess that's the real question, how would you guys handle a situation where you're pressured to deliver a deadline and you need to build a codebase from scratch where multiple people need to work on it simultaneously, where everyone's commit relies on each other
try to split the work so it doesn't interfere as much as possible
Is a valid strategy really what we did where it's like 'everyone push to one branch and tell each other when we pushed' lol
That's a good point but I don't think we had the requirements or knowledge ahead of time to scope things out properly
if you can't, maybe even reexamine how your project is structured, no project you can work on for multiple days should be one or two files
Yea totally true
Definitely some good takeaways from this experience and these comments
and worst case, what me and my colleage did, was just work on our own things. The person that was done first was rewarded by not having to solve the merge conflicts
and if it's multiple days of work, sync your work as often as you reasonably can
you should be able to pull changes from a different feature branch I think? It's been a long time since I used git extensively though
You definitely can and that's something I should have thought of tbh
I think you hit the nail on the head though about trying to scope things out, there were a lot of things popping up during our sprint that we were learning for the first time and had to rewrite the code. So I think having a detailed understanding before we write can help us scope out what each person does and we can make feature branches during that time too
I doubt our code would be totally encapsulated though, so we'd still need to pull from feature branches but it shouldn't be as bad as it was this time around
oh, it can never be totally encapsulated
that's a pipe dream
all we can do is our best, but real life is messy and sometimes you just both need to work on a central file for whatever reason, it happens
Pushing to dev directly is known as trunk based development and very common. It's got a lot of benefits over feature branches.
Feature branches run the risk of becoming stale or long lived, which makes it harder to merge. If two people are working on isolated feature branches for a week without submitting to dev, those branches easily become conflicting. Or even if there's no git conflict, perhaps someone else just pushed changes to an api to dev and now the feature branches no longer compile. The one major benefit of feature branches is that you get code reviews through pull requests. Also for large overhauls or projects that just take a bit longer to figure out, feature branches work better since you can commit just to backup your work and lets multiple people contribute to the same unfinished feature
Trunk based development is very common in games which usually use something like perforce instead of git since it handles large binary files like assets better. You just submit your commit directly to the repo's main/dev branch. What's nice about this is that if you push and pull often, you're always on the latest state. You encounter breakage quicker and not at the end of your feature. Combined with CI to report when the dev branch doesn't build, this makes dev usually pretty stable already. You're always using and improving it and if there's a bug, all programmers notice it quickly and are encouraged to fix it quickly. You're also incentivized to write your code in a more modular way. Code patterns like feature switches and dependency injection allow you to add new funtionality without breaking the old. Like pushing an experimental feature that can be enabled through a config change. This is great for avoiding merge conflicts and your customers can also try out the new feature quicker even if it's unstable, which shortens the feedback loop
I'd say either way works better or worse for different projects. Coordinating will always be the best option to avoid stepping on each other's shoes
Trunk based dev also helps to encourage programmers to try and chunk their feature into smaller little parts that can be pushed independently. Not always possible of course but if you think about code like that early on it can also help with your architecture in the long run
Great info, thank you!! 🙂