On Thursday, 14 May 2020 15:54:31 UTC+10, Magnus Therning wrote: > > > SJW <[email protected] <javascript:>> 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] <javascript:> > 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 >
I'm going to try this approach and see how I go. The only hurdle I can see is comparing master to production - If there are 4 branches merged into master that aren't in production yet and only 1 of those branches is approved for production, how do I merge only "some" of the master branch? -- 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/4f6daddb-18bb-4a7a-a3db-c64ef5643b1a%40googlegroups.com.
