\n
The term \'Content First\' has been bandied about for a couple of years now and over that time it has come to mean different things to different people. A common driver behind these variations is the concept of mobile first design. At least as far as thinking about how best to deliver content to smaller devices with limited screen real estate. Whilst there is certainly a confluence between these two approaches, I\'ll concentrate on the former here and write up a separate article on the latter.
\nSome of the different takes on content first that I have encountered include:
\nIn my opinion they each bring some value to the table, and a combination of them all can bring yet more value.
\nAs far as I can trace back, this concept began with a blog post from Mark Boulton entitled A Richer Canvas. Mark points out that whilst there have been unquestionable principles for content layout in use for hundreds of years, these rules and methods begin with paper. "Paper that has edges, ratios that can be repeated." Designing for the web does not of course provide us with the luxury of a defined \'canvas\' or repeatable page. Mark suggests:
\n\n\n"...we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out."
\n
Shortly after, Jeremy Keith made a follow up post and coined the term \'Content First\'. Jeremy talks mostly about layout here and in particular how that content can be presented differently on different devices. He goes on to say:
\n\n\n"I think there\'s a general agreement amongst web designers that we should be designing from the content out but there\'s still an over-reliance on canvas-in tools like predefined grids."
\n
Regarding the limitations of screen size on mobile devices Luke Wroblewski, the originator of Mobile First, tells us:
\n\n\n"There simply isn\'t room for any interface debris or content of questionable value. You need to know what matters most."
\n
Luke is also the coiner of \'content first, navigation second\'. Which is to say, prioritise your content up front on smaller screens and minimise the navigation.
\nFrom the off, start thinking about how you can deliver an optimal experience for users of smaller devices, phones, tablets, phablets (I guess it sounded better than \'tones\'?), etc. This doesn\'t mean just thinking about your layout and navigation (although these are obviously important elements). It also means thinking about your content and specifically which content is important. This means finding the right balance of what you want to push out to your readers and what your users actually want. A little research here can go a long way!
\nGet your ruthless head on and cut the crud! Bin all that fluff that doesn\'t really need to be there other than for the purpose of filling a space on larger screens. Warning! As the power surges through your newly liberated self, carving through your content like a hot knife through butter...try not to get too carried away. If a side bar provides truly useful supporting information, then fine...it gets to live and see another day.
\nOnce you have your optimised content, let\'s help your users to access this goldmine of information in an efficient way. When I load up a website on my mobile browser, I don\'t want to have to scroll down through swathes of site header artifacts like logos, taglines, search boxes, and let\'s not forget your all important site navigation. I want the \'good stuff\' and I want it now! Or in other words, prioritise your content. There are various tried and tested methods of minimising the valuable screen estate used by your site navigation whilst providing a more meaningful user experience appropriate to that device. I\'ll get to that later in a Mobile First article.
\nThe variations in layout and presentation that we have referred to here are possible through another much talked about design approach, Responsive Web Design. One of the key principles of RWD is the use of CSS media queries which allow us to define different styles that are \'triggered\' when a condition is met such as a particular screen size. A lot of folk create these \'breakpoints\' in their design based on common device screen sizes like 320px, 480px, etc. This however, has nothing to do with the content. It is the content itself that should dictate when the design needs to change as a screen becomes larger. Test how your content looks as you increase the screen size, and when it starts to look crap, insert a breakpoint and change your presentation to something more appropriate.
\nIn summary, de-cluttering your content can really help you focus on what is important to your readers/customers/target audience and, more importantly, allow them to access this content more efficiently. Defining the breakpoints in your layout where the design fails the presentation of your content is more useful than just following assumed device dimensions.
',frontmatter:{teaser:"The term 'Content First' has been bandied about for a couple of years now and over that time it has come to mean different things to different people. From prioritising content over navigation, to saying goodbye to Lorem Ipsum.",date:"07 November 2013",path:"/blog/content-first-I-want-the-good-stuff-and-I-want-it-now",title:"Content First: I want the good stuff and I want it now"}}},pathContext:{prev:{html:'\n
There are several branching strategies out there but none more popular than Vincent Driessen’s GitFlow model. His model allows for the usual mainline master and dev branches, and also feature, release and hotfix branches. This may be overkill for some, but if you have more than a few developers working on the same team and on several different features of the same codebase, it can help you to hang on to your sanity (what little you have left anyway).
\nThe original blog post above is an excellent reference, but I wanted to provide a more detailed workflow. The examples below employ quite a verbose usage of the various Git commands for clarity’s sake. For example I always include source/destination branches (local and remote) when pulling, pushing, merging, etc. If you are certain your branch tracking is setup correctly, you can of course use the shorter form commands. Personally, I don’t like to leave things to chance so I would rather be explicit and confident of the expected outcome.
\nThe master branch is automatically created when you create a new Git repository. Master branch should only store code that is \'release\' ready. Deployment to live/production is only ever done from a tag created on this branch.
\nThe dev branch is sometimes referred to as the \'integration\' branch. It begins life as a branch from master. All developed code (from feature branches) is eventually merged into this branch. Dev branch reflects the current state of \'developed\' code but not necessarily release ready (a release may require several features).
\nFeature branches provide an isolated environment to develop an application feature without the risk of potentially harmful changes either from you or other developers affecting each others code. This means you can experiment and even ditch your feature without any impact on other development. Feature branches are always created from, and eventually merged back into dev branch. Once merged, they can be deleted as all your feature code is now in dev branch.
\nRelease branches allow us to take a snapshot of the code at any given time and effectively freeze it from any other development. When any finished features branches have been merged back into dev branch, tested and are ready for production, we can checkout a release branch from dev. On occasion the release may need to be ‘polished’ with some minor changes (no new functionality here!). When complete, the release branch can be merged into master, tagged with a release number i.e. 3.2, tested and deployed. Don’t forget to also merge the release branch back into dev to add any release tweaks that might have been made. As with feature branches, release branches have a limited existence, they can be deleted once merged with master and dev branches.
\nSo your new feature passed all the tests you created, was included in a release and is now out in the wild on your live website. Then boom! You notice a bug that wasn’t captured by your tests. Depending on the severity, you may need to roll back your production environment to the previous release tag. Whatever you do though, you’re going to have to fix that bug. This is where we create a hotfix branch from master to implement our bug fix. Once complete we can merge the hotfix into master, tag it with a release number i.e. 3.2.1, test and deploy. As with release branches, we also need to merge the hotfix into dev branch to fix the same bug there.
\nFeature branches are always branched from dev.
\n$ git checkout -b my_feature_branch origin/devAny work completed is then committed to your local working copy of the feature branch. You can of course also push this branch to origin if anyone else needs to work on elements of this feature.
\n$ git push origin my_feature_branchThey can then checkout their own working copy of the feature branch.
\n$ git checkout -b my_feature_branch origin/my_feature_branchAs with any branch, after you have committed your changes but before pushing it to origin, you must pull from origin to ensure all code is merged correctly and fix any merge conflicts that might occur.
\n$ git commit -m”my awesome feature changes”\n$ git pull origin my_feature_branch\n...\n... if any merge conflicts, fix and commit again\n...\n$ git push origin my_feature_branchWhen a feature is complete, it must be merged back into dev. Note that if dev branch has been altered since the feature was checked out, you may have some merge conflicts to fix. These must resolved and committed.
\n$ git checkout dev\n$ git pull origin dev\n$ git merge --no-ff my_feature_branch\n$ git push origin devNote the use of the --no-ff option. If dev had not changed since we checked out the feature branch, Git could simply fast forward when merging. This however results in a linear history with no recollection of a feature branch ever existing. By telling Git to not allow a fast forward merge, a commit object is created and the history of the feature branch is retained.
\nOnce the feature branch has been successfully merged, it can be deleted both locally and on origin as it is no longer required. Note you may have to change branch as you can’t delete the branch you currently have checked out.
\n$ git checkout dev\n$ git branch -D my_feature_branch\n$ git push origin :my_feature_branchIf you are using Git 1.7.0 or above you can also use the following alternative to delete remote branches:
\n$ git push origin --delete my_feature_branchWhen you have all the required features for your next release merged into dev and tested, you are ready to create a release branch.
\n$ git checkout -b release_3.2 origin/devAny minor tweaks can be made and committed to this release branch. There shouldn\'t be a need to push this branch to origin unless several developers need to collaborate on the tweaks. Remember the rule here is no new functionality. When the release is complete and tested, we can merge it into dev and master branches. We can also delete the release branch once merged.
\n$ git checkout dev\n$ git pull origin dev\n$ git merge --no-ff release_3.2\n$ git push origin dev\n$ git checkout master\n$ git pull origin master\n$ git merge --no-ff release_3.2\n$ git push origin master\n$ git branch -D release_3.2Now let\'s cut a tag on master.
\n$ git tag -a v3.2 -m"Release 3.2"\n$ git push origin master --tagsThis tag can now be tested and ultimately deployed to production.
\nWell done, give yourself a pat on the back. You\'ve done a great ... what\'s that you say? Someone has reported a bug? I don\'t think so, not in my ... oh yeah, look at that! So we now have a bug on our live application. Best get working on a hotfix!
\nWhen you’re done, as with release branches, you must merge the hotfix into both dev and master branches then delete it. We can then cut a new tag for testing and deployment.
\n$ git checkout -b hotfix_3.2.1 origin/master\n...\n... various magic performed and committed here\n...\n$ git checkout dev\n$ git pull origin dev\n$ git merge --no-ff hotfix_3.2.1\n$ git push origin dev\n$ git checkout master\n$ git pull origin master\n$ git merge --no-ff hotfix_3.2.1\n$ git push origin master\n$ git branch -D hotfix_3.2.1\n$ git tag -a v3.2.1 -m"Hotfix Release 3.2.1"\n$ git push origin master --tagsNow rinse and repeat!
\nCheck out my Git cheat sheet for a quick reference guide to the most used commands.
',id:"/home/geoff/www/cornerpiece/geoffford.co.uk/src/pages/blog/06-02-2014-git-branching-and-release-strategy/index.md absPath of file >>> MarkdownRemark",frontmatter:{date:"2014-02-06T12:01:05Z",path:"/blog/git-branching-and-release-strategy",title:"GIT Branching & Release Strategy"}},next:{html:'\n
A quick reference guide to the most common and useful Git commands.
\nCreate a new local repo from existing files.
\n$ cd myproject\n$ git init\n$ git add .\n$ git commit\nClone an existing remote repo
\n$ git clone git://example.com/myproject\n$ cd myproject\n... or just the repo contents (note the . at the end of the clone command)
\n$ mkdir myproject\n$ cd myproject\n$ git clone git://example.com/myproject .\n$ git status\n# On branch master\nnothing to commit (working directory clean)\n$ git branch -a\n* master\n remotes/origin/master\nCheckout a new local branch (and switch to it) then create remotely too.
\n$ git checkout -b dev\nSwitched to a new branch \'dev\'\n$ git branch -a\n* dev\n master\n remotes/origin/master\n$ git push origin dev\n$ git branch -a\n* dev\n master\n remotes/origin/dev\n remotes/origin/master\nCheckout an existing local branch, update from remote, merge in another and update to remote.
\n$ git checkout master\nSwitched to branch \'master\'\n$ git pull origin master\n$ git merge dev\n$ git push origin master\nAdd new files to be tracked and commit.
\n$ git status\n# On branch master\n#\n# Initial commit\n#\n# Untracked files:\n# (use "git add ..." to include in what will be committed)\n#\n#\tmyfile.html\nnothing added to commit but untracked files present (use "git add" to track) \n \n$ git add myfile.html \n \n$ git status\n# On branch master\n#\n# Initial commit\n#\n# Changes to be committed:\n# (use "git rm --cached ..." to unstage)\n#\n# new file: myfile.html\n# \n \n$ git commit -m"My commit message"\n[master (root-commit) b46f4f8] My commit message\n 0 files changed\n create mode 100644 myfile.html\nAdd modified files via interactive method to be staged and commit.
\n$ git status\n# On branch master\n# Your branch is ahead of \'origin/master\' by 2 commits.\n#\n# Changes not staged for commit:\n# (use "git add ..." to update what will be committed)\n# (use "git checkout -- ..." to discard changes in working directory)\n#\n#\tmodified: anotherfile.html\n#\tmodified: myfile.html\n#\nno changes added to commit (use "git add" and/or "git commit -a") \n \n$ git add -i\n staged unstaged path\n 1: unchanged +1/-0 anotherfile.html\n 2: unchanged +1/-1 myfile.html \n \n*** Commands ***\n 1: status\t 2: update\t 3: revert\t 4: add untracked\n 5: patch\t 6: diff\t 7: quit\t 8: help\nWhat now> 2\n staged unstaged path\n 1: unchanged +1/-0 anotherfile.html\n 2: unchanged +1/-1 myfile.html\nUpdate>> 1-2\n staged unstaged path\n* 1: unchanged +1/-0 anotherfile.html\n* 2: unchanged +1/-1 myfile.html\nUpdate>> \nupdated 2 paths \n \n*** Commands ***\n 1: status\t 2: update\t 3: revert\t 4: add untracked\n 5: patch\t 6: diff\t 7: quit\t 8: help\nWhat now> 7\nBye.\n$ git status\n# On branch master\n# Your branch is ahead of \'origin/master\' by 2 commits.\n#\n# Changes to be committed:\n# (use "git reset HEAD ..." to unstage)\n#\n#\tmodified: anotherfile.html\n#\tmodified: myfile.html\n# \n \n$ git commit -m"Another commit message"\n[master 85ee80f] Another commit message\n 2 files changed, 2 insertions(+), 1 deletion(-)\nSo you need to work on a different branch but have changes in your current branch that you don\'t yet want to commit. Git\'s handy Stash lets you store your current changes and then restore (apply) them when you return to the branch later.
\n$ git stash\nSaved working directory and index state WIP on master: 85ee80f Another commit message\nHEAD is now at 85ee80f Another commit message\n$ git stash list\nstash@{0}: WIP on master: 85ee80f Another commit message\n$ git checkout someotherbranch\n...\n...\n...\n$ git checkout master\n$ git stash apply\nYou can also clear your previous stashed states too.
\n$ git stash clear\nOn occasion you might need to merge a specific commit from one branch to another, rather than merge the whole branch over. You first need to find the SHA for the specific commit in the source branch. Note that you only need the first 6 or 7 characters, enough to be a unique reference. Then we can cherry-pick that commit in to the destination branch.
\n$ git checkout dev\n$ git log --pretty=oneline\n87ef1e6557ebec91ea8dd8f2eb4fc302c83a5381 cherry pick test\n85ee80f59832d2f93db64f7b6deef355e41d8e65 Another commit message\nb9a3ba26698f404b65f2182a47267cc097c34a19 adding removed file\n$ git checkout master\nSwitched to branch \'master\'\n$ git cherry-pick 87ef1e6\n[master 797180a] cherry pick test\n 1 file changed, 1 insertion(+), 1 deletion(-)\nThe usual approach to marking release points in your code is to create a tag (and then test and deploy that tag). Make sure you have the latest tags from the remote repo first before creating a new one. Also be sure to push the new tag back to the remote repo.
\n$ git pull origin master --tags\n$ git tag\nv1.0.1\n$ git tag -a v1.0.2 -m"Creating a new release"\n$ git tag\nv1.0.1\nv1.0.2\n$ git push origin master --tags\nCounting objects: 1, done.\nWriting objects: 100% (1/1), 170 bytes, done.\nTotal 1 (delta 0), reused 0 (delta 0)\n * [new tag] v1.0.2 -> v1.0.2\nOn occasion you might find that you want to bin all the changes you have made and return the current branch to it\'s last commit. What? You\'ve never started work on the wrong branch before? For the less than perfect of us (that includes me!), Git\'s Reset provides the solution. Whilst Reset comes furnished with several options for different scenarios, there is one in particular which fits our situation perfectly. Please note that this is of course destructive...you will lose all your changes since the last commit.
\n$ git reset --hard\nHEAD is now at 85ee80f Another commit message\nIf you get lost with your commits or just want to dig a bit deeper into the commit history, Git provides a great tool. Gitk allows you to not only view the actual files changes within each commit but to also view a commit graph.
\nTo view all files
\n$ gitk\nTo view a specific file
\n$ gitk /path/to/file/filename\nOr if you prefer a quick in-command-line method...
\n$ git log\ncommit 797180a46e90876f0610d3256ecff9b466ab677c\nAuthor: MyName <myname@mydomain.com>\nDate: Sun Nov 10 10:45:23 2013 +0000 \n \n cherry pick test \n \ncommit 85ee80f59832d2f93db64f7b6deef355e41d8e65\nAuthor: MyName <myname@mydomain.com>\nDate: Sat Nov 9 22:40:10 2013 +0000 \n \n Another commit message\n...and we can simplify the output too.
\n$ git log --pretty=oneline\n797180a46e90876f0610d3256ecff9b466ab677c cherry pick test\n85ee80f59832d2f93db64f7b6deef355e41d8e65 Another commit message\n