Comments on: An Alternate Git Flow for Client Work https://webdevstudios.com/2015/06/11/alternate-git-flow-client-work/ WordPress Design and Development Agency Mon, 15 Apr 2024 16:04:06 +0000 hourly 1 https://wordpress.org/?v=6.6.2 By: Aria Keiko Cereno https://webdevstudios.com/2015/06/11/alternate-git-flow-client-work/#comment-92826 Mon, 18 May 2020 15:41:50 +0000 http://webdevstudios.com/?p=11300#comment-92826 how does your team handle multiple theme development?
let’s say Developer 1 has
theme/demo1 branch
and developer 2
theme/demo2 branch

should theme/demo1 branch needed to deploy to prod first before merging the
the,e/demo2 in master?

]]>
By: Peter https://webdevstudios.com/2015/06/11/alternate-git-flow-client-work/#comment-2415 Fri, 12 Jun 2015 15:03:14 +0000 http://webdevstudios.com/?p=11300#comment-2415 In reply to Chris Reynolds.

After all, creating a tag is near-zero effort, so why not! 🙂

]]>
By: Chris Reynolds https://webdevstudios.com/2015/06/11/alternate-git-flow-client-work/#comment-2414 Fri, 12 Jun 2015 14:46:52 +0000 http://webdevstudios.com/?p=11300#comment-2414 In reply to Peter.

For stuff I push up to GitHub (plugins and themes, specifically), I’ll always use tags. The benefit there is it will automatically create a release archive for the project (e.g. https://github.com/jazzsequence/book-review-library/releases). For client work, obviously it’s a different thing, but we’ve had issues where we’ve needed to restore the production site back to a previous commit, and IMO finding the right tag is easier than digging through the commit history.

On the other hand, I tend to move my tags around a lot and delete/readd them when I end up finding a problem that needs to be fixed in that version, so I totally empathize with not doing it. 🙂

]]>
By: Peter https://webdevstudios.com/2015/06/11/alternate-git-flow-client-work/#comment-2413 Fri, 12 Jun 2015 05:38:01 +0000 http://webdevstudios.com/?p=11300#comment-2413 Great article, Chris! Very interesting.

For WordPress, I don’t really use tags, since the version number is already “hardcoded” in the plugin or theme. I normally commit with the version number as commit message right before release. That’s my tag I guess.

]]>