TGRHavoc

-- THIS IS AN EXAMPLE SCRIPT TO SHOW THE USAGE OF THE REVERSE WEAPON FILE

local equippedLabel = "collision_o4mlk9" -- "~a~ equipped"

function showWeaponText(weaponLabel)
    BeginTextCommandDisplayHelp(equippedLabel)

    AddTextComponentSubstringTextLabel(weaponLabel)

    EndTextCommandDisplayHelp(0, 0, 1, -1)

TGRHavoc

function _drawSprite(dic, texture, posX, posY, sizeWidth, sizeHeight, heading, colour)
    -- Make sure sprite dictionary is loaded
    while not HasStreamedTextureDictLoaded(dic) do
        Wait(100)
        RequestStreamedTextureDict(dic, true)
    end

    -- NUI Calculations
    local screenW, screenH = GetScreenResolution()
    local height = 1080

TGRHavoc

There are many Git workflows out there, I heavily suggest also reading the atlassian.com [Git Workflow][article] article as there is more detail then presented here.

The two prevailing workflows are [Gitflow][gitflow] and [feature branches][feature]. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited.

When using Bash in the command line, it leaves a bit to be desired when it comes to awareness of state. I would suggest following these instructions on [setting up GIT Bash autocompletion][git-auto].

Basic branching

When working with a centralized workflow the concepts are simple, master represented the official history and is always deployable. With each now scope of work, aka feature, the developer is to create a new branch. For clarity, make sure to use descriptive names like transaction-fail-message or github-oauth for your branches.