Jump to content
Search Community

Gitflow / Banners

Matt Severin test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi all, in the near future my department will be practicing gitflow when versioning our banner projects.


The standard gitflow branches are nice. But I wanted to find out if any of you have discovered modified workflows serve banner development, since, banner dev isn't really analogous to software development. 

I look forward to your thoughts.

  • Like 2
Link to comment
Share on other sites

Banners might not be analogous to full-on software development, but it gets pretty similar to websites/microsites.


In my experience they go through the exact same processes as a website does, just expedited.


I've never worked with Gitflow itself, but I love Git for developing banners, it just makes so much sense to have a nicely ordered way to version control your code.

I guess the workflow you will create will depend on how you and your team like to work.


I've used branches as a way to version control different languages.


So working on a whole European campaign, I created a set of master banners as English, then:

git checkout -b french
git checkout -b german
git checkout -b dutch
git checkout -b spanish

I then used a script to append the branch name to the deployment script, so each preview link had its own language.


This kept it not only consistent but very straight forward for devs who weren't familiar with the project to pick up easily.



Another workflow is creative routes as branches

git checkout -b feature/route-a
git checkout -b feature/route-b
git checkout -b feature/route-c

With the master branch always being the main creative route/idea.


My main pet peeve is git commit messages, making sure people are concise and informative with their messages.


And follow this style guide: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#type


I'm not sure what if there is a name for it, but it makes sense and its pretty easy to follow.


The only other thing I added was "amend:" as a new type because we all know client amends are going to be in there all the time, and they're not really a "refactor:" or a new "feat:"

joe_midi 2eb47c1 amend: remove drop shadow from CMB lockup sprite
joe_midi d2185e5 docs: update README
joe_midi 397e9ae amend: speed up transition to right-hand side
joe_midi de45d11 amend: right-panel background no longer has transparency
joe_midi 0eb7b38 chore: update backup.jpg
joe_midi d057f72 fix: make product labels retina fixes font in issue #7
joe_midi 156a7f2 amend: legal line to appear only when you hover over a product
joe_midi d2d45fc feat: add legal line
  • Like 4
Link to comment
Share on other sites

I use gitflow for software/web dev and have also applied a simplified implementation of it to banner dev. Work off the dev branch, merge up to master and tag releases. I haven't seen any merit it using release/feature/hotfix branches for banner dev, same goes for small software projects. 


If the entire campaign gets changed I'll take a tag to mark the version (version-1 etc) before butchering everything up on develop.


I currently store all the banners in the branch as subfolders. 


One repo is one campaign

One subfolder is one banner variation (creative/size/language) - each folder contains a gulp build task.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...