We develop our brand visual identity design to ensure it stays relevant in the market and reflects the benefits and quality of our product. We are the creative partners for GitLab marketing. We create, conceptualize, and design high quality brand experiences.
Why we exist
As stewards of the GitLab brand, our goal is to educate and enable the wider organization with resources to effetively and honestly communicate what the company does to our internal and external audiences.
Where we're going
The GitLab Brand Design team will elevate the brand beyond the logo and visuals - positioning ourselves as experts in brand strategy and behavior (how the brand presents itself, how it's precieved, and what makes it authentic)
What we do
Create simple, effective, and intentional brand experiences by solving complex problems; defining the what, why, and how, resulting in a message that's easy to understand.
Please fill out one of these Issue Templates to request support. Please note, if these are not filled out we won't have the proper information for us to support your request.
The best way to get in contact with the Brand design team is to fill out one of the above issue templates with your request, or to:
In certain cases, the help of a third party agency or design partner may be brought in for a project. The following serves as criteria for when to outsource design:
Whenever a third party is brought in to support design, the work must be shared with the Brand Design team to ensure brand integrity and that we are working transparently with one another.
In the past we have accomodated internal team logo requests, typically in the form of customized tanukis. As our company grows, this approach is not scalable for the Brand Design team. Additionally, altering the logo or using too many logos diminishes the integrity of our brand identity and dilutes our brand awareness. We understand the desire for teams within GitLab to have their own identity, but this should not be prioritized over the business value that comes from preserving our core branding. For this reason, all designs should complement and adhere to our brand guidelines.
If your team works on a larger initiative, please refer to our program lockup guidelines. These lockups should be used in conjunction with the GitLab logo and branding. If you are unsure if your program or initiative requires a lockup, please contact the Brand Design team.
We are all brand designers, brand champions, critically thinking problem solvers, strategists, and teammates – leveraging each others' strengths while growing our collective knowledge and expertise. We work by following GitLab’s values and using issues and epics to track our work.
The team should feel empowered to make the best decisions possible for the GitLab brand while seeking structured and direct feedback from the team as often as possible. Adam and Luke are here to make final decisions as needed, but do not need to be the bottleneck of progress.
#marketing-designslack channel. (3) Wednesday design hours call where we get feedback and collaborate on topics that need to be addressed.
designissue labels to show up on our team’s triage board. Adam and Luke triage work at the beginning of the week, and team members are able to assign work to themselves, too. We use issue weights (1 weight = approx. 4 hours of work) to measure bandwidth and milestones to track capacity for each week. Everyone can see their work for the week by looking at their individual issue board.
#brand-design-teamslack channel. Drafts are typically shared async with the stakeholder using the design tab in issues or as a screenshot in comments.
_artwork) and another folder for your exported files (ie: png, exports, pdf, etc.).
corporate-marketingrepository to your machine. For your day-to-day work, here are the typical git commands for pulling and pushing work, in the order of which they should be used:
cd corporate-marketing- this command only needs to be used once upon opening the Terminal app. The
cdcommand may need to be done multiple times, followed by the parent folder name where you’ve stored the repository on your device, until you get into the
git pull- this updates your local repository to mirror any changes made by the rest of the team; do this command before starting work or pushing any new work
git status- optional command; this provides a summary of all the changes you’ve made locally that need to be pushed back the repository
git checkout [insert file path
]- optional commnand; this can be used to remove any files you do not want to push to repository
git add .- use this command before pushing your work; it will add all the files you have made changes to
git commit -m “[insert description of changes]
”- include a message with a summary of your changes; this is viewable to everyone and provides context
git push origin master- this will push all your changes back to the repository, including the commit message to describe the changes
git pull --rebase, followed by,
git push origin master- use these two commands to reset if you receive an error when pushing