Using Git for WordPress Theme Development: Simplify Workflow, Collaboration, and Version Control

Now that we have Full-Site Editing built into WordPress, theme development is so much easier. But we still want to keep our code in a Git Repository.

Git is an invaluable tool for WordPress theme development, whether you are modifying older-style themes or when developing full-site editing themes.

Using Git can greatly enhance your workflow, collaboration, and version control.

If someone else collaborating on the project modifies a file that you also modified at your computer, or if you make changes at different computers, you can easily merge them with Git.

With Git, you can easily review, discuss, and approve changes through pull requests. You can specify the purpose of each change, to make reviewing easier.

Git has good tools for resolving conflicts, where changes by multiple people affect the same file. Each set of changes are tracked, and then you can review exactly what changes were made in any file and make any adjustments so all the changes can be combined.

Git’s version control allows you to pinpoint the exact commit where a bug was introduced, making it easier to identify the cause and fix it quickly. You can quickly roll back to a working version if you find that changes introduced a problem. Publish the prior version to your production sites, fix the problem, test it, commit the new code to your repository, and publish the new code to production.

How do you Simplify Using Git for Your Common Theme Changes?

You don’t need to learn all the features of Git. There are a few commands you will use frequently. The others you learn only when you need them.

For themes, most of your code will be very similar in future themes you make, except for the color palette. With Git, you can easily go through every feature you improved in a recent theme, and apply the improvements to other themes as needed. While you can’t automate applying the changes from one project into another, at least you can see exactly what changes were made and copy/paste those changes into the other project.

You are probably making themes by yourself, even if you work in a company with many themes being developed.

Whether for a simple theme or for a theme package, you use Git the same way; you publish your changes to the repository for this one theme, with your name and date/time.

When it is time to release the whole package of many themes, Git can merge the repositories for the final product, without modifying the individual theme’s repositories. (You can learn later how to make a “combination” repository. I won’t cover that here, and it is well documented.)

Folder Structure for Local Development and GIT

The normal process is you develop all your theme’s files in your local repository and then push the files to a GitHub repository to publish to your live sites.

Have a folder on your computer for your theme. That folder will include a local Git repository.

Have another folder for your local WordPress development environment for testing the theme.

Then, have a repository on GitHub (or similar), available on the Internet. You will use this for publishing to production sites. Of course, this is also a backup should anything happen to your computer.

I have a folder for all my websites, ~/sites, and then in that folder I have one folder for each site or plugin or theme. Examples: ~/sites/wordpress/ (local development environment) and ~/sites/mytheme/ and ~/sites/abc-theme/ and in each of the theme folders have a Git repository, e.g. ~/sites/mytheme/.git/

Note that leading period, .git, which means the Git repository is a “hidden folder”. Use your ls command with the -a flag (ls -a ~/sites/mytheme) to see it.

Then I have folders for the theme, such as mytheme/assets where I put fonts, mytheme/images where I put theme icons, etc.; and mytheme/parts for block editor patterns and full-site editing page parts.

ls -a
.  ..  assets  .git  images  parts  readme.txt  screenshot.png  style.css  templates  theme.json

ls -a parts
.  ..  comments.html  footer.html  header.html  navigation-with-images.html  post-meta.html

Why not have the Git repository inside your local development folder?

For local development, I recommend you don’t put your local repository in the development environment folder.

If you are done with the local development setup, it is quite normal for you to shut down the local development environment and delete the folder.

Oops, you would have deleted your local Git repository. You should also have the Git repository replicated on GitHub, but if you didn’t…

Another reason to keep the folders separate is to avoid inadvertently getting WordPress or other themes and plugins, into your Git repository. You can tell Git to ignore folders and files (git ignore command), but it is simpler this way.

You will find it is easy to copy files from your theme folder into your testing folder.

Only put in the repository the essential files for re-creating your theme, including fonts and icons and style sheets.

Getting Your Files Into Git

You can start with a new folder, create a Git repository in it, and add your theme files to the folder. Or, add your theme files to the folder and then create a Git repository in the folder.

I use Lando: A development tool for all your projects that is fast, easy, powerful and liberating but the local development environment most popular among the AZ WordPress Meetup is Local – Local WordPress development made simple localwp.com

Creating a Git Repository (local)

When you create a Git repository, a hidden folder is added to your current folder. That folder contains the Git repository. The rest of your current folder is unchanged.

cd ~/sites/cyb-theme/
git init

Git responds: Initialized empty Git repository in /home/george/sites/cyb-theme/.git/

Now in ~/sites/cyb-theme/ there is a new folder, ~/sites/cyb-theme/.git

Commands for Initial Commits

GitHub used to name the main branch “master” and has changed the standard branch to “main”.

You can use the git status command to see what the current branch name is. For example:

git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

“On branch main” is what you want. If it says “On branch master” you can change it. This command won’t do anything until after your initial commit.

git branch -M main

Settings for Your Local Git

Each commit should have your name and email specified. If you configure Git with your name and email, that will make your Git command lines simpler.

Use these commands to configure the Git software on your computer, to be used in all your projects:

git config --global user.name "George Lerner"
git config --global user.email "george@YOURDOMAIN.com" 
git config --global --list
    user.name=George Lerner
    user.email=lernerconsult@gmail.com

There are a lot of options you can set in Git. To find them, use the git –help command. You mostly won’t need to change any options, but here is how you change them:

git config --edit

That command opens the configuration file in a text editor.

Now you are ready to add files to your local Git repository.

Add the current files to your local Git repository

git add --all

This command tells Git to add all the files in the current folder, to the list of files you will be tracking in your repository.

Alternatively, you can “git add” followed by one or more file names.

You can get the status of the repository, for example which files are “new” (have not been committed to the repository) or which files have been modified since the last commit.

git status

Committing Changes to the Repository

When you have all your changes done (for this set of changes), and all the files ready in the status, it is time to Commit the changes to the repository.

If you are fixing multiple bugs, you might find it easier to make each bug fix a separate set of changes. That keeps your “commit comments” clear. Specify which files to commit, if you don’t want to commit all changes. If you are using a bug tracker program, put the commit ID in the tracker.

When you commit changes, you should always add a comment. The comment should state what the group of changes is for, such as fixing a bug or adding a feature. The comment will help you identify which commit you want to refer back to for adding these changes to another theme.

If you don’t specify a commit comment, Git will automatically open a text editor for you to enter one.

git commit -m 'Initial commit theme files, created by create-block-theme plugin, plus icons needed for the theme'

The entire comment has to be inside quotes, or only the first word would be taken, and then you would have the other words as unexpected parameters. (Or, leave out the comment on the command line, and Git automatically loads a text editor for the comment.)

Note that you have to be careful if you use single or double quotes in a comment, so no apostrophe-s if you have the comment surrounded by single quotes. (Using the comment text editor should handle apostrophes properly.)

Your name (specified in the Git configuration file or by the git config commands above) is added to the commit, unless you specify --author= in the command line.

Similarly, the current date and time is automatically added to the commit.

Before you commit, you can add --dry-run to the command to see what the commit would do, but no changes are made to the repository.

There are many more options available for the git commit command. I recommend reading git --help commit

Ignoring Files in Git

You should only add to your repositories the files that need to be there. Don’t add temporary files (from your editor, for example), and don’t (at least accidentally) add your WordPress installation or plugins from the WordPress Repository.

Note: Never put anything confidential in any Git repository, public or private, as they are designed to be published. That includes passwords, WordPress configuration settings (such as, but not only, your wp-config.php file), and your business confidential information.

Learn more about ignoring files I used the gitignore.io tool specifying VisualStudioCode (my programmer editor), Kate (my general text editor), WordPress, and Linux (my computer is Linux Mint, you can specify Windows or OSX).

Making a GitHub Repository for your Theme

You want a GitHub (or similar) repository, since it is available on the Internet, instead of just on your computer.

You can make GitHub repositories public, or private (only accessible to you or people you explicitly share it with).

Since you will transfer information to the GitHub repository, do not initialize the GitHub repository with a README; or at least don’t make one in both your local repository and your GitHub repository. Do make a gitignore file and add a license on GitHub. Note: If those resources exist in both repositories before the git remote add origin command runs, that will create extra merge and conflict resolution steps that are easily avoided.

Setting Up a GitHub Repository for WordPress Theme Development

Set up a GitHub repository for each project (plugin, theme, etc.) You will make one account, for you or your company. In that account, you create many repositories.

GIT local to remote

In each project, make a .git/config file

For project in ~/sites/asdf make a ~/sites/asdf/.git/config file.

Below is an example config file. For yours, make these changes:

• replace the url from GitHub that is the “SSH” URL (on the GitHub page for the project, click the <>Code button, in Local click SSH and copy the URL that starts with git@github.com: and then your GitHub username and then the project.

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = git@github.com:glerner/website-tech.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

If GitHub version not in sync

I let one theme project get started on GitHub, then made a repository from scratch on my computer. When I tried to push my theme to GitHub, it wasn’t done right (should have made the repository on GitHub, then cloned it to my computer).

~/sites/cfal$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 2 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean
george@GL-Lat3410:~/sites/cfal$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.
george@GL-Lat3410:~/sites/cfal$ git config pull.rebase false
george@GL-Lat3410:~/sites/cfal$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 2 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean
george@GL-Lat3410:~/sites/cfal$ git pull
fatal: refusing to merge unrelated histories
george@GL-Lat3410:~/sites/cfal$ git config pull.rebase true
george@GL-Lat3410:~/sites/cfal$ git pull
Successfully rebased and updated refs/heads/main.
george@GL-Lat3410:~/sites/cfal$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Now everything is good

git push
Enumerating objects: 18, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 8 threads
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 190.07 KiB | 1.78 MiB/s, done.
Total 17 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), done.
To github.com:glerner/cfal.git
   5aa878f..9226d6f  main -> main

Frequent Command Flow for Updating Your Repository

git remote add main [url]

Specifies the remote repository for your local repository. The url points to a repository on GitHub.

You can use the command git remote set-url to change a remote’s URL.

git push
fatal: The current branch main has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin main

https://training.github.com/downloads/github-git-cheat-sheet/

Publish the local repository to GitHub

GitHub – Setting up SSH agent forwarding https://docs.github.com/en/authentication/connecting-to-github-with-ssh/using-ssh-agent-forwarding#setting-up-ssh-agent-forwarding

git push

Uploads all local branch commits to GitHub

Adding changes to your files, into the repository

Update the GitHub repository from your local repository

Publish the GitHub repository to your production site(s)

Rolling back to an earlier version of files

Checking the Status of the repository

What changes were made between any two versions?

• This is an list item
• Another item

== Here is ChatGPT stuff

Setting Up a GitHub Repository for WordPress Theme Development

As an individual developer working on WordPress theme development, setting up a GitHub repository can greatly enhance your workflow and collaboration capabilities. Here are the best steps to set up a GitHub repository:

Step 1: Create a GitHub Account

• Visit the GitHub website (https://github.com/) and sign up for a new account if you don’t already have one.
• Choose a username, enter your email address, and set a secure password.
• Complete the verification process to activate your GitHub account.

Step 2: Create a New Repository

• Once you have a GitHub account, log in to your GitHub dashboard.
• Click on the “+” icon in the top-right corner and select “New repository” from the dropdown menu.
• Give your repository a descriptive name related to your WordPress theme.
• Optionally, add a brief description to provide more context.

Step 3: Configure Repository Settings

• Choose between making your repository public or private. Public repositories are visible to everyone, while private repositories require access permission.
• If needed, add a .gitignore file to specify files and folders that should be ignored by Git (e.g., caching files, sensitive data).
• Select the appropriate license for your WordPress theme. It’s recommended to use an open-source license like MIT or GNU GPL.

Step 4: Clone the Repository to Your Local Machine

git clone <repository_url>

Replace “<repository_url>” with the URL of your GitHub repository. This command will create a local copy of your repository on your machine.

Now you have successfully set up a GitHub repository for your WordPress theme development. You can start committing your theme files, creating branches for new features, and collaborating with others using Git’s powerful version control features.