3 ms·
A common case for git branches is long-life versions. For example, one git branch can be for version 1.0 and one git branch can be for version 2.0. This can be
by jph 3y ago
A common case for git branches is long-life versions. For example, one git branch can be for version 1.0 and one git branch can be for version 2.0. This can be good for major upgrades, as well as for site-specific installations, as well as for regulated industries that need to audit specific versions.
- zck 3y agoSo we have a git branch v1, and a git branch v2, and sometimes we pull commits into both, and other times just one. How does pijul manage that without using channels?
- IlliOnato 3y agoI think the most common use for git branches is topic branches. Independent lines of development you are not ready to share with your team, or your team with the rest of the company, or commit to production. I don't see how Pijul features can remove the need for such lines of development. I also don't see how it matters whether a branch is long-lived or not. What Pijul may help with is a (broken, IMHO) workflow of some Git projects where the long-standing branches are constantly rebased. This workflow is bad, but having branches in Git does not force you to (mis)use rebase. I am not saying anything against Pijul, and maybe there is a better way than branches to manage multiple lines of development, but I'd like it to be explained. So far I cannot guess what it might be.