Re: [git-users] Git workflow recommendations
SJW 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: mag...@therning.org 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 git-users+unsubscr...@googlegroups.com. 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
[git-users] Git workflow recommendations
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. -- 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 git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/498e2275-2592-4dbc-9c8a-eedecf13c102%40googlegroups.com.
Re: [git-users] git stash
Kunal Chauhan writes: Hi Kunal, > I gone through the git doc but I am not able to do the git stash > particular file > > like 1. >>>git stash show //its some some 2 files +++ and > > but I tried > :>> git stash push -m "message " filepath > above command is working ? git stash -h shows --8<---cut here---start->8--- usage: git stash list [] or: git stash show [] [] or: git stash drop [-q|--quiet] [] or: git stash ( pop | apply ) [--index] [-q|--quiet] [] or: git stash branch [] or: git stash clear or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [-m|--message ] [--pathspec-from-file= [--pathspec-file-nul]] [--] [...]] or: git stash save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [] --8<---cut here---end--->8--- so it must be git stash push -m "message " -- filepath That filespecs go after a double-dash is quite common with git. For example, if you want to checkout only some file of a given revision, you'd also use something like git checkout -- path/to/file Bye, Tassilo -- 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 git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/871rnoz5fh.fsf%40gnu.org.
