Git

Suggested by Les, meeting 7/25 with Alex, AJ R, Tim, Cameron, Roger, Kim and Scott notes below.

  • Aligning all projects with this format
  • Formality, helpful for onboarding/ others seeing your code
  • Topics: Code review process, branching, never solo on projects, need support!
  • Code reviews on every single ticket
  • When you start a project, branch off of master or develop
    • Prefered standard to branch off of develop
    • Some maintenance will happen branching off of the master
    • Lead developer merges back into master and deploy
    • Git solves for conflict discrepancies between start points
  • For smaller projects where stability is less important, it’s okay to branch off of master
  • If there are no active tickets, master and develop will be the same.
  • Master is more stable
  • Naming conventions
    • Integrations with Jira
    • Important to use jira ticket number (i.e. GH-1) in git branch
    • Ex. making a branch for GH-1:
      • git pull 
      • git checkout (switch to different branch) -b (switch to make new branch) GH-1_fix-the-header (name that is descriptive)
    • To merge back in: not sure where someone else is on project? Always good to check. Remember branch name but check out master 
      • git checkout master
      • git pull (pull latest copy of that)
      • git checkout your_branch_name 
      • git merge master (ensure your branch is up to date with master)
  • Pull requests: choose two branches, (merge to and merging from), shows changes visually for pull request, assigns someone to review. Slack has integration, pull requests show up here 
  • Only pass pull requests if:
    • Review general code style (ex. Intentation, does it look good visually)
    • Right implementation
    • Documentation (ex. Mandate updating shade store wiki)
  • Controls deployments
    • Never make edits in master and push it live
    • Works if you’re perfect, but we like to QA/ code review and keep others in the loop
  • Code shouldnt spend any time in master and not on live
  • Deployment is generally automated (when pushing to master or develop)
  • In order to QA:
    • Either push your branch up to the staging server, or
    • Merge your changes into the develop (or stage) branch and deploy to staging
  • No release branch
    • Test on develop (or stage) and then push live once approved
  • We will be integrating pull requests into our normal flow going forward
  • Pull request rules
    • As long as one other person is signing off on pull request it can go through
  • Code review step in Jira?
    • Not in all of them, might want to turn this on
  • GUI, not gooey, for git?
    • Dan Ash and AJ M might use
    • Alex thinks they create excessive flags and get weird
  • No jedi force pushes or rebases
  • When to do staging server?
    • Annoying to not have one for QA purposes, must QA on developer’s computer
    • Only need for high volume though…
  • Formality → risk management
  • Hotfixes
    • If you’ve never done before, don’t deploy yourself
    • Still do a pull request
    • For a site branching off of the master, hotfix is like any other project
    • If branching off of develop, have many changes, and need to do a hotfix, do hotfix on master not develop
      • Then merge master into develop
      • Get that hotfix change
      • Back to normal
  • Git is a nightmare for undoing something
    • Just call Greg
    • If you haven’t committed the change yet and you realize it is in the wrong branch or someone else did it
      • git checkout — name (gets rid of changes since you made that branch)
    • Forget to create branch for ticket? Have a bunch of changes that you need to take to another branch?
      • git stash
      • Git checkout branch
      • Git stash apply (all of them) and git stash drop OR pop (off the end)
        • Recently stashed, bring them onto the branch you’re on
        • If you were accidentally on master and want to swap and bring your changes to deploy, usually resolves changes 
    • Git stash revert
    • Edge case
      • 6 branches, some are merged in develop, QA fails one of them
      • Usually all can rest in develop for a while (low urgency unless hotfix) until they are all ready to be merged into master
  • Git cherrypick
    • Only get your changes to a branch off of master so you can only push that live, not any other changes
  • In local master branch, won’t pull in latest

Leave a Reply

Your email address will not be published. Required fields are marked *