SJW <shannon.whi...@gmail.com> writes: > On Monday, 6 July 2020 22:22:49 UTC+10, Magnus Therning wrote: >> >> >> SJW <shanno...@gmail.com <javascript:>> writes: >> >> > I am still trying to get my head around the best possible way to use git >> > (and failing) >> > >> > Here is my normal process below - but I don't like it because it is very >> > difficult to manage repos and versions. Hoping someone can read this and >> > advise me on improvements or tell me that this is just how git works... >> > >> > Code bases: >> > - DEV (local PC - this is where local git repo is configured - and >> origin >> > is GitLab) >> > - STAGING (server - I have a local folder synced with server) >> > - LIVE (server - I have a local folder synced with server) >> > >> > Effectively I have 3 local folders with 3 codebases (STAGING and LIVE >> are >> > just syncd to server) >> > >> > 1. I create a branch - *new-branch-1* >> > 2. I develop new branch >> > 3. I use WinMerge to sync DEV changes with STAGING >> > 4. I submit changes in *new-branch-1* to QA team to review and approve >> > >> > 5. I create a branch - *new-branch-2* >> > 6. Make more changes for a separate task/project >> > 7. I use WinMerge to sync DEV changes with STAGING >> > >> > *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are lots >> of >> > files showing that I need to manually filter through and ignore and try >> and >> > find the specific changes from new-branch-2 >> > >> > 8. I submit changes in *new-branch-2* to QA team to review and approve - >> We >> > now have both branches in STAGING >> > >> > 9. QA come back with some changes or improvements for *new-branch-1* >> > 10 I checkout *new-branch-1* and update the code with the >> recommendations >> > from QA >> > 11. I use WinMerge to sync DEV changes with STAGING >> > >> > *ISSUE#2*: Same as issue#1 now I need to manually filter out the changes >> > from new-branch-2 >> > >> > 12. Repeat with *new-branch-3* - Meanwhile, someone else has added >> > *new-branch-4* and *new-branch-5* to staging >> > >> > *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code branches >> - >> > it's starting to become very difficult to identify branch specific code >> in >> > STAGING >> > >> > 13. QA approves *new-branch-2 *- I merge *new-branch-2* back to master >> > 14. Compare master with LIVE and update the LIVE code with all the >> changes >> > >> > It just becomes very confusing and overwhelming when you start getting >> lots >> > of branches so I end up halting development and waiting for QA but this >> is >> > inefficient and slows development. >> > Does anyone have any suggestions on how I can streamline this to avoid >> > delays in development? >> >> I think you've put your finger on the issue, QA is too slow. You can do >> manner of fixes to tools and processes, but you'll always be hindered by >> QA being slow! >> >> A few things you can try in the meantime: >> >> - don't use git for deploy, instead use CI/CD >> > > I did try that but wasn't comfortable having git update code without > visually seeing the changes it was making - not that comfortable or > trustworthy yet
Maybe we're talking past each other, but I'm saying /don't use git for deploy/. Use `git archive` to get the latest version on a branch into a ZIP archive (or .tar.gz, or whatever) and then use some way of deploying the stuff in that archive. >> - spin up one staging for each branch you develop on >> > > That seems like a lot of effort for each branch. Would probably be > ideal but ... That's effort that should be automated, via your CI/CD. You check in, then wait a few minutes and voila, you have a staging server for the branch you pushed. Automation, automation, automation. :) >> In the end I think the only long-term solution is if QA is folded >> into development, i.e. that you move the organisation to >> cross-functional teams, including QA. > > Cant see it happening - there is 4 of us - 2 separate companies doing > this as a side project - so I get 1-2 days from them per week Then I see two options: - you continue being miserable and the project limps along, or - you find a place where you have more chance of contributing positive change Just my 2ct :) /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/87zh89g138.fsf%40therning.org.
signature.asc
Description: PGP signature
