Create a page for your GitHub project

A page is a great way to have a portal for the various open source projects your organization maintains or about how to use products from your organization. Some great examples of projects out there include:

All of the above have some things in common, that I think are important:

  • The branding is consistent(ish) with company guidelines, so the experience isn’t tooooo dissonant with the main pages
  • The salesy part of the branding has been stripped out
  • The experience is putting useful content for developers right up front
  • Most assume some knowledge of scripting, consuming APIs, and other technical needs
  • They showcase and include information to projects
  • Projects from multiple accounts are included (even projects owned by other organization if they help put developing more open source projects out there)

Taking all this into account, let’s make a page! To get started, first create a project in your GitHub account with the url of <accountname>

Create an index.html page in there (even if it’s just a hello world page). At this point, you’re just writing standard html. You can have standard tags like H1, H2, etc – and import a css elements from another place.

I really like is displaying cards for your GitHub projects. One project that I like to use (I must have tested 30-40) is GitHub-cards. To use that you’ll need to enable Java, as you can tell from the .js. Then you just include a line to display that card, replacing the data-github field contents with the username/projectname of any projects you want to include, as follows (e.g. for the GitHub user/org name jamf and the GitHub project name of KubernetesManifests):

<div class="github-card" data-github="jamf/KubernetesManifests" data-width="400" data-height="" data-theme="default"></div> <script src="//"></script>

One final note, many an organization has a standard css they want to be used when building new web properties, including something like a GitHub site. You can leverage these by calling them out in the header as follows:

<link href="" rel="stylesheet" type="text/css" media="screen">

According to how much is involved in how a given CMS mucks up code, you might have a lot of tweaking to bring elements in and consume them to your orgs spec, but it’s much easier than sifting through rendered source to figure it out on your own. Once published, go to the account (in this example, and viola, you have a new page!

Git Quick-start

Git it easy. It’s a command with some verbs. Let’s start with the init verb, which creates an empty git repository in the working directory (or supply a path after the verb)

git init

Now let’s touch a file in that directory. Once a new file is there, which that new repo as your working directory, run git  with the status verb:

git status

Oh look, you now see that you’re “On branch master” – we’ll talk branching later. You see “No commits yet” and hey, what’s that, an Untracked file! Run git with the add verb, and this time you need to specify a file or path (I’ll use . assuming you’re working directory is still the directory of your path).

git add .

Now let’s run that status command again. And hey, it sees that you now have a staged file (or files). 

Now let’s run our first commit. This takes the tracked and staged file that we just created and commits it. Until we do this we can always revert back to the previous state of that file (which in this simple little walkthrough would be for the file to no longer exist). 

git commit -m “test”

Now let’s edit our file and this time let’s run git with the diff verb:

git diff

Hey, you can now see what changed between your file(s). Easy, right? Check out the logs to see what you’ve been doing to poor git:

git log

Hey look, there’s a commit listed there, along with an author, a date and time stamp, as well as a name of the file(s) in the commit. Now, let’s run a reset to revert to our last commit. This will overwrite the changes we just made prior to doing the diff (you can use a specific commit by using it as the next position after —hard or you can just leave it for the latest actual commit:

git reset —hard

Now this resets all files back to the way it was before you started mucking around with those poor files. OK, so we’ve been working off in our own little world. Before we explore the wide world that is cloning a repository off the interwebs, first we’re going to do a quick look at branches. You know how we reset all of our files in the previous command? What if we had 30 files and we just wanted to reset one? You shouldn’t work in your master branch for a number of reasons. So let’s look at existing branches by running git with the branch verb:

git branch

You see that you have one branch, the “* master” branch. To create a new branch, simply type git followed by the name of the branch you wish to create (in this case it will be called myspiffychanges1):

git branch myspiffychanges1

Run git with the branch verb again and you’ll see that below master, your new branch appears. The asterisk is always used so you know which branch you’re working in. To switch between branches, use the checkout verb along with the name of the branch:

git checkout myspiffychanges1

I could have done both of the previous steps in one command, by using the -b flag with the checkout verb:

git checkout -b myspiffychanges1

OK now, the asterisk should be on your new branch and you should be able to make changes. Let’s edit that file from earlier. Then let’s run another git status and note that your modifications can be seen. Let’s add them to the list of tracked changes using the git add  for the working directory again:

git add .

Now let’s commit those changes:

git commit -m "some changes"

And now we have two branches, a little different from one another. Let’s merge the changes into the master branch next. First, let’s switch back to the master branch:

git checkout master

And then let’s merge those changes:

git merge myspiffychanges1

OK – so now you know how to init a project, branch, and merge. Before we go on the interwebs let’s first setup your name. Notice in the logs that the Author field displays a name and an email address. Let’s see where that comes from:

git config --list

This is initially populated by ~/.gitconfig so you can edit that. Or, let’s remove what is in that list:

git config --unset-all

And then we can add a new set of information to the key we’d like to edit:

git config "Charles Edge" --global

You might as well set an email address too, so people can yell at you for your crappy code some day:

git config “” --global

OK, optics aside, let’s clone an existing repository onto our computer. The clone verb allows you to, —insert suspense here— clone a repository into your home directory:

git clone

The remote verb allows you to make a local copy of a branch. But it takes a couple of steps. First, init a project with the appropriate name and then cd into it. Then we’re going to grab the url from GitHub:

And add it using the remote verb:

git remote add AutoPkg

Now let’s fetch a branch of that project, in this case, master:

git fetch test myspiffychanges1

Now we’ll want to download the contents of that branch:

git pull myspiffychanges1

And once we’ve made some changes, let’s push our changes:

git push test myspiffychanges1

Run a script directly from github

There are a lot of scripts stored on github. And you can run them directly by curling them into bash. To do so, you’ll need a link to the raw script (using the github page with the URL of the script brings in all the cruft, so you’ll need to find the raw text). To grab that, click on the page with the script and then right-click  on Raw, as seen here: Screen Shot 2016-04-16 at 11.21.48 PM Then, throw out a bash command followed by < and then the URL you just copied into your clipboard in parenthesis:
bash <(curl -Ls

Simple Swift Project To Run A Bash Script When A User Clicks A Button

New project on Github to run a bash script when a user clicks on a button. This is pretty basic, easily customizable, lots of stuff you could add, and with a license I’m sure anyone can appreciate. Screen Shot 2016-03-08 at 8.26.13 PM Hope you enjoy.

Mac DevOps Conference

There’s another new conference in town! Well, not my town, but Vancouver. MacDev Ops is a hot topic. One that will only increase in the coming years. Thanks to Mat X and Brian Warsing for bringing about a brilliant conference. Screen Shot 2015-03-23 at 10.43.50 PM The conference will be held on June 19, 2015 and is an easy $99 if you sign up soon. Also, submit a talk if DevOps is your thing. They’re looking to bring the following topics to the table:
  • Puppet, Chef and other automation from Desktop to Cloud and back
  • Software deployment with Munki and AutoPkg: the app ecosystem surrounding it
  • Cool tools: demo of awesome Mac Admin projects from GitHub
  • DevOps: How to adopt Automation and Best practices in IT operations
  • Dev skills: workshops on Ruby, Git, Python, Javascript for Mac Admins
  • MDM: Profiles and Mac configuration management in the cloud
This is sure to be a good one. Check it out here!