SJW <[email protected]> writes: > New to Git and I'm using a basic workflow that I'm not sure is that good so > wanted to post it here for feedback, critique and suggestions if possible. > > Dev = Local Win 7 PC > Staging = Staging Server > Production = Live Site > > 1. Develop on a branch (new-feature) > 2. Add, Commit, Push to origin:GitLab > 3. Using WinMerge: Compare Dev Branch Code to Staging Code and manually > copy changes to local "staging" code > 4. FTP modified Staging files up to Staging server > 5. Dev on new branch (new-feature1) and do the same (steps 2-5) * > 6. Testing performed on branch (new-feature) and approved for Production > 7. Merge approved branch (new-feature) into master > 8. Add, Commit, Push to origin:GitLab > 9. Using WinMerge: Compare Dev master to Production Code manually and > copy changes to local "Production" code > 10. FTP modified Production files up to Production server > 11. Delete branch > > * This is where comparison is not great - because new branch doesn't have > previous branch changes and thus is highlighted in WinMerge as different > files (and therefore, I need to check through and make sure changes are > related to current branch and merge into Staging files). This can sometimes > be 3-4 different branches if Testing is slow and regularly, branch 4 will > be approved before branch 1. > > I think the issue at point 5 is what has me thinking this is not the best > way. > Also, I don't know how to incorporate hot-fixes - I normally just make > these changes straight to master > > I tried adding a remote for staging and production but of course - this > didn't work because pushing changes to staging will remove the previous > branch changes allowing for testing of only on branch at a time.
I'd consider using two branches and then say that - `master` is what's deployed to staging - `production` is what's deployd to production Then - skip step 3, you already know what should be in staging, it's what's on `master` - modify step 4 and use `git archive master` to get an archive of what should be deployd, get that into staging somehow (I'd prefer `rsync`) - skip steps 6-11, instead run tests agains `master` (what's in staging) and when you are happy, fast-forward `production` branch to match `master`, and - deploy `production` in the same way you deployd to staging The next step after that would be to set up Gitlab CI so deploys to staging happens automatically on merges/pushes to `master` and to production on pushes to `production`. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: [email protected] twitter: magthe http://magnus.therning.org/ It is better to keep your mouth shut and appear stupid than to open it and remove all doubt. — Mark Twain -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87mu6bhxiv.fsf%40therning.org.
signature.asc
Description: PGP signature
