Is using Git tags the appropriate way of tracking advances?

[Rod-at-DOH]

Select Topic Area

Question

Body

Where I work, we used to have TFS. That resulted in several project management practices, which I believe are now a hold over, now that we've adopted Git and GitHub.

One such practice commonly used here, is when deploying a new web application, someone will make a copy of the current one into a folder named Current. A before they make that copy, they move what's in Current to another folder, naming that new folder something that includes the date. Consequently, we have a large number of folders all with dates in their names for previous versions of the web app.

I'm thinking a better approach is, when we've got a version of the web app that we like, then create an annotated tag associated with that commit. Then if we have to revert to some previous version of the web application, we pull that commit associated with that tag. Is that a good approach? Could it be improved?

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Rod-at-DOH]

I'm still interested in recommendations as to the best way to do software architecture using GitHub.

[vinaybembalge]

Yes—replacing the “copy-a-folder-with-a-date” ritual with annotated Git tags (or GitHub “Releases”, which are just tags with metadata) is the modern, source-controlled way to mark deployable builds.
You keep the history inside Git instead of on a file share, every version is reproducible, and your CI/CD pipeline can automatically deploy the exact commit tied to a tag.

Why tags beat dated folders

Single source of truth – The tag points to the exact commit you shipped; no one has to guess which files went into “2024-05-16”.

Immutable & traceable – Tag history lives in the repo clone, so you can compare, diff or rollback with one Git command.

Works with automation – Most CI/CD platforms, including GitHub Actions, allow you to trigger a build or deploy job whenever a tag that matches a pattern (e.g. v*) is pushed.

Clean workspace – You no longer accumulate dozens of dated copies on disk.

Good practices to adopt

Use annotated (or signed) tags
Annotated tags store the author, date and message; signed tags add cryptographic proof.

text
git tag -a v1.2.3 -m "Release notes here"
git push origin v1.2.3
Follow semantic versioning
The MAJOR.MINOR.PATCH scheme communicates the scale of change and is widely understood by tooling and humans alike.

Automate tagging and deployment
A GitHub Actions flow can cut a tag and deploy it in one push event, eliminating manual steps and typos.

Trigger on merges to main or on a manual “Release” workflow.

Build, test, publish artifacts, then actions/create-release (or git tag) and deploy.

Different environments, different tags (optional)
If you promote the same commit through dev → staging → prod, environment-specific tags—v1.2.3-dev, v1.2.3-prod—let you see exactly what’s live where without extra branches.

Attach release notes & artifacts
On GitHub, publishing a “Release” for the tag lets you add changelogs and upload compiled zips or container images. Operations can then fetch the artifact instead of rebuilding.

Room for improvement

Immutable build artifacts – Instead of checking out source on the server each time, have CI produce a signed package or container image tagged v1.2.3 and deploy that.

Rollback automation – A one-click “redeploy tag X” script (or environment promotion in GitHub Actions) cuts rollback time further.

Branch protection & checks – Require tests to pass before a release tag can be created or pushed to main.

Bottom line
Tagging the release commit and letting CI/CD deploy from that tag is the industry standard. It removes manual copying, adds traceability, and dovetails with automated testing and rollback, giving you a cleaner and safer release process.

[holakirr]

Yes, using Git tags is an appropriate and widely recommended way to track advances, releases, and deployments in your project.

Why Git tags are a good approach:
• Tags mark specific points in history: Git tags are designed to reference important commits, such as releases or stable versions, making it easy to identify and revert to a particular state of your codebase.
• Annotated tags add context: Annotated tags can include metadata like the tagger’s name, date, and a message describing the release, which is useful for documentation and traceability.
• Standardized and integrated: Tags are a built-in feature of Git, making them easy to standardize across teams and integrate with CI/CD pipelines for automated deployments.
• No need for manual folder copies: Using tags eliminates the need for manual folder management with date-stamped backups, reducing clutter and human error.
How to improve this approach:
• Use semantic versioning: Adopt a clear versioning scheme (like v1.0.0) to make releases more understandable.
• Automate with CI/CD: Set up your deployment pipeline to trigger builds and deployments based on tag creation, ensuring consistency and traceability.
• Push tags to remote: After creating a tag locally, push it to your remote repository so the whole team can access it:
git push origin <tag-name>
• Reverting to a previous version: If you need to roll back, you can simply checkout the commit associated with the relevant tag:
git checkout <tag-name>

Summary:
Switching from manual folder copies to Git tags is a best practice for modern version control and deployment workflows. It brings clarity, traceability, and automation to your release process.
Let me know if you need example commands or more details!