On Monday, 6 July 2020 22:17:45 UTC+10, Philip Oakley wrote: > > This is some 20,000ft observations about how conflicting mental models and > processes may be causing trouble. > > A thought in the background: it's generally considered poor practice to > think of Git as a deployment system, so one has to be careful at the final > step of deployment that only the deployable files are actually deployed, > rather than having a full public-facing git repo available for cloning > (along with all the in development branches and ones with secret keys etc > etc). So that final step could be the pure sync of the checked out branch > alone. >
> Elsewhere it sounds like you are not using the power of Git to keep you > branches separate right through the QA/Test process. In steps 7 & 11 you > say you are WinMerging part of your work into an *uncontrolled* folder > (if it was controlled & versioned it would use a git command!!). > Wanted to eventually get tot this but dont have enough experience or trust in git to allow it to modify the code without letting me see it. Preferred manual so I knew exactly what was going on. TBH - I have really struggled with git and am probably a long, long way off automating deployment. > > It maybe that the QA/Test haven't yet got the same mental model about how > the git checkout removes automatically any old or outdated files (like an > old fashioned slide viewer doing a 2-card trick), and swaps in the correct > files for the checkout. It's likely that you haven't trained the QA/TEST > folks how to add markup and commit their comments so that they are part of > the repo, such that the checkout happens cleanly (as opposed to say the > folder is dirty because their comments are hanging > unresolved/uncommitted...) It maybe that you get them to create a branch > *new-branch-1-QA* from the tip of your branch to add all that > 'crap^WCommentary' that you need to resolve the issues on *new-branch-1* > QA have never touched or even heard of git. So you're right, they definitely don't have the "same mental model". TBH I dont trust git so definitely wouldn't feel comfortable with them checking code in and out. > > *Use git all the way until the final deployment*. Don't let any issues > happen because you aren't using the tool's (Git) strengths (cheap easy > branching!). Avoid mixing tools (hammers, screwdrivers vs screws and nails) > Would love to be in a position where I trust git enough to be able to do this. > > Philip > > On Monday, July 6, 2020 at 2:28:01 AM UTC+1, SJW wrote: >> >> 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? >> > -- 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/efd9f094-ac6a-4df6-9472-6a6d248d8b45o%40googlegroups.com.
