SJW <shannon.whi...@gmail.com> 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 - spin up one staging for each branch you develop on 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. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org twitter: magthe http://magnus.therning.org/ You can't depend on your judgement when your imagination is out of focus. — 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/877dvgj0jd.fsf%40therning.org.
signature.asc
Description: PGP signature
