EngineeringWiki
  • Introduction
  • Top level Overview of the application
  • FAQs
  • Back End
    • Agent Pipeline
    • Mention Pipeline
    • Profile Pipeline
    • Errors
    • Overview of the Mention/Profile/Cluster Process
    • Adding a New Service
    • Activity and Status Tracking
  • Setup
    • Overview
    • How to Setup Your Local Machine
    • Setup - Cloud Machine
    • Infrastructure
    • Docker
    • Bash Commands
    • Setting up front end in Ubuntu 16.04 desktop
  • Gems/Libraries
    • Bax
    • Creating fixtures for Unit Tests
    • Audienti-Retriever
    • Scour
    • Haystack
    • Audienti-Indexer
    • Audienti-Api
    • Handler
    • Blackbook
    • Allusion
  • Code
    • Multi-step Modal Wizard
    • Structure
    • Audienti DataTables
    • Javascript
      • Passing Props From Root
      • Looping in JS
      • Binding Actions to App
      • CSSTransitionGroup
      • Code Best Practices
      • Reducer Updating an Array with Item in Middle
      • Organizing Javascript
      • Filter Array by Id
    • Design Language
  • Working
    • PostgresSQL
    • S3
    • Terminology
    • Interview Tests
    • Application Descriptions
    • Best Practices
      • Code Organization
      • Code Documentation (using Yard)
      • Git Workflow
      • Tasks and Queues
      • Working in Backend
    • Profiles & Enrichment
      • Profile ID Rules
  • Management
    • API Management
    • Bastion
    • Splash Proxy
    • Rancher
      • OpenVPN Server
      • Traefik Reverse Proxy
  • Teams & Interviews
    • Interview Questions
  • Culture
    • What Makes a World Class Engineer
  • Situational Statuses
    • 2017-11-03
    • 2018-01-09
  • Operations
Powered by GitBook
On this page
  • The general process
  • Issuing a pull request
  • Branch naming
  • Pull requests
  1. Working
  2. Best Practices

Git Workflow

PreviousCode Documentation (using Yard)NextTasks and Queues

Last updated 7 years ago

The general process

You will branch from master to do your work. Ideally, your branch must be connected to a github ticket/issue. But, if not, you can omit the id. On your local, please do:

 git fetch 
 git checkout master 
 git checkout -b 3021_wf_fix_problem

where the "fix problem" is a 2 to 3 word description of what you're trying to do.

Once you do this, work on your branch. It's a good idea, once a day or so, for you to rebase off of master. This will incorporate updates from master into your local flow, and make things easier later if you diverge significantly.

Every day, make sure you remerge master. This will make your final pull request much easier.

Once you're ready, you push your branch using ITS BRANCH NAME to origin. This will run circleci tests on it. ONce they are green, and you're ready to go, issue a pull request for this, and let someone know.

Issuing a pull request

When you are ready, push your branch, and then go to Github.com and to your repo. You will likely see your own branch at the top, highlighted.

Click the compare and pull request. Or, if its not highlighted, click the Pull Request button in line with the "This branch is X commits..."

From there, You will receive a screen where you describe your pull request.

If the base says "Able to merge" then you are all set. Describe what you did and click the green "Create pull request" button. If it is red, you need to go back and merge the current master, and make sure there are no conflicts.

Once you do this, let you manager know and they will handle the merge from here.

Go back to master, and start from there. Make sure you pull the most recent.

Branch naming

Your branch must be connected to a Github issue. To achieve that start the branch's name with the ticket's ID number followed by a dash '-'. Then continue with your initials and a description of the the branch.

Example: **3018-aj_links_tld_chart

  • Issue ID: 3018

  • Owner: aj - andrej jančič

  • Description: links_tld_chart

Pull requests

All pull requests should be running from CURRENT master, and should not have code conflicts with master. If you have a master conflict, the pull will be rejected, and you will be asked to make it current with current master.

When you are ready to issue a pull request for a review of your code (not necessarily for a merge), then you should write a description that states the changes you are making, as compared to the master. Are you fixing? Are you adding a new item? State it.

Once you issue a pull request, let your manager or merger know, so they can merge the information.