5 ms·
If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to lo
by yakubin 5y ago
If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something.
(Every non-official build is made from a separate branch.)
- Freak_NL 5y agoDeployed versions that need to be referred to later usually get git tagged, but those are not that much different from branches of course (they'll both show up in autocomplete as a committish object). But even then; tens of thousands of tags/branches? At that point it might be worth considering simply baking in the git commit hash into the build artefact for future reference instead of tagging every CI build with a branch/tag.
- yakubin 5y agoWhen I say "non-official", I say that it has some commits that aren't on the main branch. You need to push them somewhere, or else they're going to be lost.
- samatman 5y agoYou may not have much choice in the matter, but this level of complexity is where I would strongly recommend a (slightly) more complex architecture. It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only. Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.
- danw1979 5y agotags might be a more suitable way of... tagging those releases for future reference ?
- yakubin 5y agohttps://news.ycombinator.com/item?id=28025573 https://news.ycombinator.com/item?id=28025573