4 ms·

> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time

> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.

eddd-ddde 10mo ago
Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that aren't ready, so you just cherry pick the fix to your release. It's branches in a way, but _only_ release branches. The only valid operations are creating new releases from head, or applying cherrypicks to existing releases.
- imiric 10mo ago
  I don't see how you're avoiding development branches. Surely while a change is in development the author doesn't simply push to main. Otherwise concurrent development, and any code review process—assuming you have one—would be too impractical. So you can say that you have short-lived development branches that are always rebased on main. Along with the release branch and cherry-pick process, the workflow you describe is quite common.
  - ozozozd 10mo ago
    Their dev branch is _the_ development branch. They don’t do code reviews or any sort of parallel development. They’re under the impression that “releases are complex and this is how they avoid it” but they just moved the complexity and sacrificed things like parallel work, code reviews, reverts of whole features.
    - eddd-ddde 10mo ago
      I'm not sure where you got that from. There is a single branch, which obviously has code review, and reverts work just the same way. What there isn't, is long lived feature branches with non-integrated changes.
- WorldMaker 10mo ago
  That's where tags are useful because the only valid operations (depending on force push controls) are creating a new tag. If your release process creates tag v0.6.0 for commit 123 your tools (including `git describe`) should show that as the most recent release, even at commit 234. If you need to cut a hotfix release for a critical bug fix you can easily start the branch from your tag: `git switch -c hotfix/v0.6.1 v0.6.0`. Code review that branch when it is ready and tag v0.6.1 from its end result. Ideally you'd do the work in your hotfix branch and merge it to main from there rather than cherry picking, but I feel that mostly because git isn't always great at cherry picking.
- RaftPeople 10mo ago
  > Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. And you've personally done this for a larger project with significant amount of changes and a longer duration (like maybe 6 months to a year)? I'm struggling to understand why you would eliminate branches? It would increase complexity, work and duration of projects to try to shoehorn 2 different system models into one system. Your 6 month project just shifted to a 12 to 24 month project.
  - eddd-ddde 10mo ago
    Can you clarify why it would impact project duration? In my experience development branches vastly increase complexity by hiding the integration issues until very late when you try to merge.
    - RaftPeople 10mo ago
      The reason I said it would impact duration is the assumption that the previous version and new version of the system are all in the code at one time, managed via feature flags or something. I think I was picturing that due to other comments later in the thread, you may not be handling it that way. Either way, I still don't understand how you can reasonably manage the complexity, or what value it brings. Example: main - current production - always matches exactly what is being executed in production, no differences allowed production_qa - for testing production changes independent of the big project production_dev_branches - for developing production changes during big project big_project_qa_branch - tons of changes, currently being used to qa all of the interactions with this system as well as integrations to multiple other systems internal and external big_project_dev_branches - as these get finalized and ready for qa they move to qa Questions: When production changes and project changes are in direct conflict, how can you possibly handle that if everyone is just committing to one branch? How do you create a clean QA image for all of the different types of testing and ultimately business training that will need to happen for the project?
      - eddd-ddde 10mo ago

eddd-ddde 10mo ago

Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that aren't ready, so you just cherry pick the fix to your release. It's branches in a way, but _only_ release branches. The only valid operations are creating new releases from head, or applying cherrypicks to existing releases.

imiric 10mo ago
I don't see how you're avoiding development branches. Surely while a change is in development the author doesn't simply push to main. Otherwise concurrent development, and any code review process—assuming you have one—would be too impractical. So you can say that you have short-lived development branches that are always rebased on main. Along with the release branch and cherry-pick process, the workflow you describe is quite common.
- ozozozd 10mo ago
  Their dev branch is _the_ development branch. They don’t do code reviews or any sort of parallel development. They’re under the impression that “releases are complex and this is how they avoid it” but they just moved the complexity and sacrificed things like parallel work, code reviews, reverts of whole features.
  - eddd-ddde 10mo ago
    I'm not sure where you got that from. There is a single branch, which obviously has code review, and reverts work just the same way. What there isn't, is long lived feature branches with non-integrated changes.
WorldMaker 10mo ago
That's where tags are useful because the only valid operations (depending on force push controls) are creating a new tag. If your release process creates tag v0.6.0 for commit 123 your tools (including `git describe`) should show that as the most recent release, even at commit 234. If you need to cut a hotfix release for a critical bug fix you can easily start the branch from your tag: `git switch -c hotfix/v0.6.1 v0.6.0`. Code review that branch when it is ready and tag v0.6.1 from its end result. Ideally you'd do the work in your hotfix branch and merge it to main from there rather than cherry picking, but I feel that mostly because git isn't always great at cherry picking.
RaftPeople 10mo ago
> Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. And you've personally done this for a larger project with significant amount of changes and a longer duration (like maybe 6 months to a year)? I'm struggling to understand why you would eliminate branches? It would increase complexity, work and duration of projects to try to shoehorn 2 different system models into one system. Your 6 month project just shifted to a 12 to 24 month project.
- eddd-ddde 10mo ago
  Can you clarify why it would impact project duration? In my experience development branches vastly increase complexity by hiding the integration issues until very late when you try to merge.
  - RaftPeople 10mo ago
    The reason I said it would impact duration is the assumption that the previous version and new version of the system are all in the code at one time, managed via feature flags or something. I think I was picturing that due to other comments later in the thread, you may not be handling it that way. Either way, I still don't understand how you can reasonably manage the complexity, or what value it brings. Example: main - current production - always matches exactly what is being executed in production, no differences allowed production_qa - for testing production changes independent of the big project production_dev_branches - for developing production changes during big project big_project_qa_branch - tons of changes, currently being used to qa all of the interactions with this system as well as integrations to multiple other systems internal and external big_project_dev_branches - as these get finalized and ready for qa they move to qa Questions: When production changes and project changes are in direct conflict, how can you possibly handle that if everyone is just committing to one branch? How do you create a clean QA image for all of the different types of testing and ultimately business training that will need to happen for the project?
    - eddd-ddde 10mo ago