3

I have a react-native app that I'm planning to deploy to the stores. I have a private github repo for this app, my question is how can I keep track/copy of all my live updates on github? (github release doesn't work for me, I don't want to download the source code, I just want to have access to it anytime I need). Lets say I create a final production branch (main) on 12/20/22 and I build the apps for stores from this branch, I continue to work on the app and a couple of weeks later I merge new changes to the main branch to create a new production build, but my app from 12/20/2022 suddenly crashes, I need to go back to the 12/20/22 code and test it in order to fix the bug and send the updates over the air (expo). I thought of creating a copies of the main branch every time I create a new production app (like copy-1220222), but over the time there will be a lot of copies and I don't think that's a good solution. What is the best approach to keep the live codebase untouched?

reactjs
  • 112
  • 3
  • 10
  • It's not really clear to me what you're talking about here: reproducible builds? saved binaries? In any case Git (and GitHub) save *snapshots* as commits, so if you have a way to reproduce a previous build, and your commits hold *all* the files needed, you can simply check out the old commit and rebuild to get the original binaries. – torek Dec 20 '22 at 01:17
  • @torek, I want to have access to the code of the production app, for ex, I'll build a new app on December 20th 2022, if I want to see exact components that were included in this build after 1 year, how can I do that? checking all commits (1 year old) is not an option, creating a copy branch every time I build a new app also is not an option because then I'll have a lot of copy branches in my repo. What is the standard approach? Lets say how does the Facebook know what was included in their app that was deployed to production last December, do they keep copies of the code for each update? – reactjs Dec 20 '22 at 01:37
  • Typical practice for building a release of anything (app or not) involves creating a new tag in the repository or repositories. In the case of Git, we make the commit(s) we need in the repository/ies, and build and decide that this build is "release-worthy". Then we run `git tag` in the repository/ies to create a tag: "v1.2.3" or whatever. Then we do any security process (e.g., signing the builds) and release. Whether we save all the bits as-is, or re-build later from source, we have a tag identifying all the source files that went into the build. – torek Dec 20 '22 at 01:52
  • "Keep all the bits from each build" used to be too expensive, when disk drives cost $10/megabyte in 1984, but now that you can buy a 10 TB drive for $100 or whatever it is today (or use Amazon S3 "glacier"), "keep all the bits from every build" tends to be cost-effective. – torek Dec 20 '22 at 01:53

1 Answers1

1

creating a copy branch every time I build a new app also is not an option because then I'll have a lot of copy branches in my repo

That is true with Subversion, not Git.
The best practice remains to use tags, which, combined with GitHub Release, allows you to browse the code at a specific point in time.
Each tag does not represent an additional copy, just a pointer to your codebase state (a specific commit) in its history.

But you need also to store the React application built to a deliverable referential like a Nexus instance (as described here) in order to be able to associate said code with a delivery, making sure to know what cas built from which code.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • thank you for reply. I have one more question, lets say I created tag (v.1.0.0 from the main branch), then I keep updating my app and merge updates into main and I create a tag v.1.0.1, but my app tag v.1.0.0 has a bug, I checkout tag v.1.0.0 and work on fixing the code, do I push changes to main? it will override my v.1.0.1 then correct? – reactjs Dec 20 '22 at 17:26
  • @reactjs That is why you maintain a release branch, which reflects only what has been released. You would merge your hotfix branch (created from v1.0.0) to release. And you would think about cherry-pick your fix to main (but this is not automatic, since a bug in 1.0.0 might not be relevant in 1.0.1). – VonC Dec 20 '22 at 18:33
  • Even for SVN a "copy-only" branch/tag without any changes was almost free, since SVN only stored the deltas between each version. No changes => empty delta => not that much to store (except for some meta data) – knittl Dec 20 '22 at 20:21
  • @knittl True. I remember now "[Cost of Branching SVN vs GIT](https://stackoverflow.com/a/25208079/6309)". – VonC Dec 20 '22 at 20:31