SEO Specialist and Developer Collaboration: Content Creation Workflow with Git

This tutorial explains how to use git for effective collaboration between SEO specialist (particularly, the person, who is optimizing content for search engines by making suggestive changes to the content, such as links placements, etc.) and web-developer (the person, who is reviewing, implementing and deploying these changes). The last one often is CMS operator (content manager), rather than developer, depending on website implementation.

In other words, this tutorial is going to be useful if the roles described are executed by different people.

The tutorial gives a look at the exact steps each side has to take in order for the effective collaboration to work out as well as giving broader explanation of these actions.

Obviously, in order to make this work, you need a repository of a text based (simple text, not html) version of the content of your site. Your SEO is unlikely to do an effective and productive work, working with the source code itself.

Markdown is a special language that was invented for exactly that – representing content of a web page in a simple text format. There are CLI tools, extension for text editors and online converters for converting HTML into Markdown. SEO can simply add markdown version of a page to a repository, before they are going to optimized it. Simply commit created file, so that git can start tracking it, then use another commit for your optimization changes.

There should be at least two branches. You can call them whatever you want; I’m going to be using live and pre-live branches. live branch serves for representing the actually live state of site’s content. pre-live is the branch, SEO commits changes to and pushes to remote for developer’s further use.

Further go instructions for developers (content managers).

Developer should start by fetching the origin (git fetch origin, rather than git pull). If there were optimization changes made by SEO, pre-live remote tracking branch will appear with new commits, further referred as needed commits.

1. Review and Deployment of Changes into Website’s Source Code by Developer

Before you integrate needed commits into live branch, you should review and deploy the commits’ cumulative changes into website’s actual code, possibly with needed corrections from your standpoint.

Here are suggested steps on how to do that and reduce the chance of missing changes:

1. Make sure you’re checked to the last commit of needed commits.
2. Do mixed reset to commit that goes before needed commits, you’ll get all changes of needed commits as modifications in your working directory. Command: git reset <commit hash>.
3. For each modified file/modification review modifications and if needed, make corrective changes from your standpoint; deploy modifications, then stage them. Claster modifications to do these steps on, in a way that is convenient for you.
4. Make a commit with an appropriate message on the corrective changes you’ve made. If you haven’t made any corrective changes at the previous step, you can either make a commit with any message (the commit will be dropped after rebase from the next step). Or you can just checkout the commit where you were after the first step and skip the next step. Command: git checkout <commit hash>; you can lookup the hash using git reflog command.
5. Rebase the commit on needed commits (after rebase, this commit becomes one of needed commits). If you’ve made the corrective changes, more than likely, you’ll have to resolve merge conflict; resolve the conflict keeping changes from the commit you’re rebasing; you can do that by running git checkout --theirs <list of conflicting files>; stage resolved modifications and continue rebase.

Now you can integrate all those changes into live branch.

2. Integration of Changes into live Branch

If there are no new commits on live after common predecessor commit of live and origin/pre-live, just update the live branch pointer to the last commit of needed commits (the same as performing fast-forward merge of these commits to live).

If there are new commits on live after common predecessor commit of live and origin/pre-live, use either merge, or rebase with updating the live branch pointer:

• Merge:
  • In case of merge conflict don’t forget to deploy resolved modifications before you stage them for commit.
• Rebase:
  • Use only in case of no conflicts with originally fetched needed commits from origin/pre-live, because it will be very hard to go back later and tell what exactly the original proposed changes were. You can try to rebase and abort (git rebase --abort) in case of a conflict with these commits. If conflicts, do merge instead.
  • In case of a merge conflict with the last commit of needed commits (one, you possibly created earlier) don’t forget to deploy resolved modifications before you stage them for commit.
  • You can do review and deployment after rebase, if you wish so; the live branch pointer should be updated to the last commit at last (when changes are reviewed and deployed) anyway.

Review, Deployment and Integration of Changes into live Branch Handled Together

You can do it with help of this command: git merge --no-ff --no-commit origin/pre-live; It ultimately creates merge commit even if fast-forward merge is possible, but it doesn’t actually commit yet, just stages files for commit, except for files with merge conflicts, they are presented in form of modifications as usual.

Here is what you do after the command above:

1. Unstage all files that are being staged.
2. For each modified file/modification: review modification(s), resolve merge conflicts and if needed, make corrective changes from your standpoint; deploy modifications, then stage them.
3. Make a commit with appropriate message on what corrective changes you’ve made, if you haven’t made any corrective changes at the previous step, leave default message.

After you reviewed, deployed and integrated changes into live, push it to remote.

Additional Notes

As you probably noticed, you should always stage each file/modification, only after you reviewed and deployed them; that way, you’re less likely to miss deploying some changes. Same thing with updating live branch pointer or performing final merge (creating commit, rather than staging for the commit): only after all changes from needed commits are live.