How to use HUGO with my team members?

support
#1

What’s the recommended way to use HUGO with team members ? For example as Intranet Homepage or something else.

This question is more general about the use of static side generators at all.
Thanks for some hints.

#2

You could use a shared Dropbox folder or git to manage conflicts. I guess conflicts is the only issue.

#3

Thanks for your info, i see. I have found this tutorial https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo-the-static-site-generator-on-ubuntu-14-04

Maybe this could be an other approach too!

#4

This tutorial suggests to install Hugo on the server. While possible, I personally would not do this - this would mean every “team member” would have to have access to your web server (opening all kinds of risks).

I suggest installing Hugo on every member PC, and using Dropbox to store the Hugo site. This way, everyone can make articles in the same site (since it is shared between everyone), but only one person would then push the generated site files to the server. This way, everyone can create content on their own machines, and they don’t need access to your linux server. Dropbox gives the ability to roll back to a previous file version if somebody messes up (also something the linux tutorial does not offer) and you don’t need to make accounts on the server for each user.

#5

ok, i will try your approach and let you know how this works for me :slight_smile:

#6

What we do for our content for Arrested DevOps is that we have everything up in GitHub. Each team member has a cloned version of the repo, and this is the process for making content changes (slightly different for “core” team members vs the people who don’t have commit bits on the GH repo itself).

Process for “external” contributors (people who write show notes for us, etc)

  1. Fork the github repo into your own account
  2. git clone your forked copy locally
  3. git checkout -b branch-name
  4. Make your edits, etc
  5. (optional) run hugo --verbose to make sure everything works properly (note: Most of our contributors probably don’t do that, as they likely never installed hugo and are just writing markdown only.
  6. git add . (this adds all the changed files to be staged for commit; better git hygiene would be to specifically name each file but whatever)
  7. git commit -m "Update episode 42 show notes" or something like that
  8. Push the commits up to YOUR forked copy.
  9. Submit a pull request of this new branch against the main repo
  10. Someone at Arrested DevOps will review the change and if cool, will merge it. Since we are using wercker for our builds, Github will actually display if the build passed before determining if the merge is allowed (i.e., if it threw any hugo errors).

The difference for people who have commit bits on the main repo is just that we don’t fork it into our own accounts; but we DO do our work in another branch and still submit a PR, even if we approve it ourselves :wink: