Skip to content

Version Control

How do you save a working version of your app?

Record a small change while the app works, then try your next idea on a branch. Keep a separate copy of the history you need to recover.

Where does your work go when you save it?

Saving in an editor changes the file on your computer. A commit records a version in your project’s history. Sending that commit to a host makes a separate shared copy of the work you sent.

The folder and its recorded history make up a Git repository. Git is the system that keeps that history. A visual client lets you see and manage it with buttons. A repository host gives you an online place to share work and discuss a change.

If a change leaves your booking page working, record just that change and name it clearly. When a later edit breaks the page, you have a working version to compare it with.

How do you try one change and recover it?

Use a disposable booking page and change one button label. This gives you a before and after you can see and a simple result to test.

  1. Save a working starting point
    Use a disposable copy with fake content and no customer records, passwords or live service connections. Open the page and check that the booking button shows a confirmation. Record the working files in a commit.
  2. Inspect one change
    Create a branch, a separate line of work, and change “Book a visit” to “Request a visit.” Open the list of changes and look for unrelated edits. Try the button again. If it still shows the confirmation, record just the intended change.
  3. Share the change only if you need review
    If you want to practice online review, send the starting and practice branches to a private repository you control. Keep it disconnected from live deployment. Open a pull request, a proposal to bring the practice change into the main branch. Check its destination and changed files.
  4. Undo a mistake and check the result
    On a separate practice branch, record a change that breaks the confirmation. Revert that commit, which records a new change that reverses it. Try the button again and check that the history shows both the original change and its reversal.

Compare tools

Scroll the table sideways to read every column.

Compare tools for saving and reviewing code
ToolWhere the saved copy livesWhere to look for the recorded version.What you can inspectHow to tell exactly what will change.What sharing takesWhat you need to send changes or review them together.What you can recoverWhat the tool can recover from its copy and where to look next.What affects the billThe main price or plan boundary.
GitGit records selected changes in the project’s local repository.Compare files before recording a change, then compare recorded versions.Local work can happen offline. Add a reachable repository and get access before sending changes to it.Undo a recorded change or restore history that exists in an accessible copy. Plan separate recovery for unsaved files and app data.The open-source Git software has no subscription fee. A remote host and storage have their own costs.
GitHubGitHub stores the committed history you send to a repository under your account or organization.A pull request collects the proposed changes, discussion and configured checks in one place.Create a private repository you control, send a branch and share it with people who need access.A separate copy can preserve the code history. Move large-file objects and review records separately.Free includes private repositories with limited features. Private branch controls, automation and storage can affect cost.
GitHub DesktopGitHub Desktop opens and manages a Git repository on your computer.See the changed files and individual lines before you choose what to record.Use the app for local work. Sign in and choose the destination and visibility before publishing to GitHub.Reverse a recorded edit in History. Another compatible Git client can open the same local repository.The client is free. Your repository host has its own plans.

What should you check before you share or merge a change?

Look at what will change, where it will go and whether the task still works. A short list of files makes it easier to see when an edit spread beyond what you intended.

Read the before and after for the changed files. If a label change also edits how customer sign-in works, find out why before combining it with the main branch. Keep passwords, API keys and customer records out of the changes. If a credential has already been shared, revoke or rotate it with the provider first.

If two people or agents are working at once, give each a separate branch and folder and agree which files each can change. Test the work together before merging. If you use an online preview that saves records, confirm its test database, accounts and outgoing services before trying the form.

Which copy do you need when something breaks?

Find out what disappeared or stopped working first. The saved code, the build people visit and the bookings customers made can each live in a different place.

Find the copy that contains what you need
What you need backWhere to look
A recorded button or page changeFind the commit in your Git history. Review the change and test its reversal on a separate branch.
Code from a missing computerCheck the remote or backup for the branch and commit you need. Clone it into a clean folder and confirm you can open the recorded version.
A working version of the live appFind the previous build with the hosting service and verify it can run against the current app data before putting it back online.
Customer bookings or uploaded filesUse a separate backup from the service that stored those records or files. Test recovery in a separate environment before restoring anything live.