My development team has been working with Git and GitHub for a while now, but I feel like we might be missing some important concepts. I’m curious about how other teams handle their version control workflow.
Our current approach:
We create feature branches for new changes, then merge them back to main. After that we commit our work locally and push everything to GitHub. For deployments, we SSH into our test server and pull from the main branch. We still haven’t figured out how to use rebase, fetch, or tagging properly.
What I want to achieve:
I’d love to SSH into our various servers and pull specific tagged releases, maybe something like “release-v1.0” directly to the server. Can this be done with one repository, or should we set up separate repos?
Should we be using git pull to get specific branches on our web servers, or is there a better way to git push with custom commands?
Is it possible to manage different environments (dev, staging, production) and release versions all within a single Git repository? Or do we need multiple repos for this?
Also, can you pull a specific tag directly?
You can indeed manage multiple environments within a single repository using tags and branches effectively. For tagged releases, commands like git checkout v1.0 or git pull origin v1.0 can be utilized. We follow semantic versioning for our tags, which helps deploy specific versions reliably. While pulling directly on production can be risky, we opt for deployment scripts that handle cloning specific tags to separate directories, making rollback simpler and keeping our production clean. As for rebasing, it’s helpful to maintain a clean history; just ensure you don’t rebase shared branches. Overall, one repository suffices for handling development, staging, and production by leveraging tags and branch protection features on GitHub.
Yeah, manual SSH works but it’s a pain once you scale up. We had the same headaches until we got our git hooks and deployment sorted out. You can pull specific tags with git pull origin refs/tags/v1.0 or do git fetch then git reset --hard tags/v1.0. One repo for multiple environments is totally fine - we use branches like develop, staging and tag our production releases. Here’s what really helped us: set up post-receive hooks on your servers so they auto-deploy when you push tagged commits. No more manual SSH and way fewer screw-ups. Also, git describe is a lifesaver for tracking which version is running where - saves tons of time debugging production problems.
your workflow’s already solid! just wanted to mention that git fetch beats git pull on servers since it won’t auto-merge anything. we do git fetch --tags then git checkout tags/v1.2.3 for deployments. also worth looking into github actions or other ci/cd tools instead of manual ssh pulls - they’ll save you major headaches when stuff breaks.