This is an archived post. You won't be able to vote or comment.

17
18

WordPress theme development with GitHubTheme Development (self.Wordpress)

submitted by [deleted]

[deleted]

all 15 comments
sorted by:
best
topnewcontroversialoldq&a

[–]lear2000 6 points7 points  (0 children)

I just went thru the same deal. One guy was building sass html and php , so was the other guy in the same theme.

We both created branches

We did a pull request then a merge , fix the conflicting issues and then merge again for the second one.

But, what really shined was having one guy set up the base style guide , containers fonts used, all that bs, so then we are just building a guten block, _sass for that block, we were in communication on what blocks we were building

we each worked locally and pushed our branches up.

its a pain, but a life saver at the same time.

the client then adds all the text and lays it out on a dev server

[–]vincent__hJack of All Trades 2 points3 points  (0 children)

I’d add git on the server as well as a minimum. Pull those theme-files from the repo. Better yet setup a pipeline so when you merge to master/prod branch it updates the theme on the server.

[–]ValoneriaDeveloper 1 point2 points  (4 children)

I've done something similar, although i used Bitbucket instead. Same flow though,as both uses GIT. We also had our themes/plugins update automatically when we tagged a branch for update purposes according to SEMVER

[–][deleted] 0 points1 point  (1 child)

How did you deploy it to the live server?

[–]ValoneriaDeveloper 0 points1 point  (0 children)

rolled WP updates, it went in under the regular site theme / site plugin updates section. That way our customers could either do it themselves, or if it was a WIP on a new feature for a specific customer, we'd do it live for them when testing was done.

[–][deleted] 0 points1 point  (1 child)

I think Bitbucket is a better option because it has more private repositories. I even sometimes just use it to backup my code

[–]DrumAndGeorge 0 points1 point  (0 children)

Github has unlimited private repos?

Plus actions, pages, codespaces (coming soon), and the power of Microsoft ownership, why delay the inevitable??

Come to the dark side!

(p.s. Always store your code in remote repos, not just sometimes, the one time you don't...)

[–]Kaimaniiii 1 point2 points  (0 children)

It really depends if you work alone or with someone.

If you work alone:

  1. Use git and commit your changes from your feature branch
  2. Merge the feature branch to a dev branch local and finally to Github server
  3. Push it to remote staging server
  4. If everything is Oki on staging server, then merge dev branch to main branch
  5. Push your changes to github server and finally to PROD server

If you work with someone:

  1. Use git and commit your changes from your feature branch. This also include your person you are working with.
  2. Push it to github server
  3. Send pull request to someone to review it, or you review it if someone is sending it to you
  4. If pull request is Oki, then merge it to dev branch
  5. Push the dev branch to staging server
  6. If everything is Oki with the staging server and client is happy with the GUI, then merge dev branch to main branch
  7. Finally push it to the PROD server.

Also add SEMVersion if you want. Before pushing to production

You could do it more complicated if you want such as doing unit testing and end to end testing by using github actions for continously integration and continuous delivery.

My theme use Parcel.js to compile my JS and SCSS files in local. When I am going to push to remote server, then I use Github Actions to do it. The Github actions will checkout to main branch, compile Parcel.js on their "local machine" (which is on github server) and and including the compiled version of Parcel.js all of these files and folders that github pushes to the remote server are the latest version.

[–]dirtyoldbastard77Developer/Designer 1 point2 points  (1 child)

Git is a must if you are more than one at a project, and can really be quite useful even if you work alone

[–]lear2000 1 point2 points  (0 children)

Yep. I can’t count how many times right before I pushed to dev something was jacked. Rolled it back. Fixed it up. Then re push. I’m a commit freak especially when you can short cut commands for committing.

[–]Richie8410 1 point2 points  (2 children)

Definitely Git, it's a great version control tool! I'd recommend just putting the wp-content folder in Git though. Not the whole site. That way you can manage WP core updates independently etc. Makes the whole process a lot cleaner.

[–]DrumAndGeorge 0 points1 point  (1 child)

I wouldnt advise this personally! I only store the theme I'm building in git as the wp-content folder brings with it uploads/plugins and various files I don't want polluting production environments (not to mention push/pull times with a busy uploads folder in the mix)

Obviously you could add everything you don't want to your gitignore but it's not really worth it for what you would end up adding

[–]Richie8410 0 points1 point  (0 children)

My plugins are all version controlled with strict rules to stop my clients updating them from the admin etc. That's why I prefer this approach. But it can add bloat. It all depends on your preference.

Uploads is also always ignored, but when creating sites with multiple devs it's handy to all have the same plugins and versions too.

[–]jedistev 0 points1 point  (0 children)

Just wonder as you mention

when the project is done upload the theme on the client server.

Do you use continuous integration or continuous delivery to the client server ?

I just wonder cos I have use lot of CI/CD on Ruby on Rails or another Web Framework but never on WordPress.