\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\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.
',id:"/home/geoff/www/cornerpiece/geoffford.co.uk/src/pages/blog/07-11-2013-content-first-I-want-the-good-stuff-and-I-want-it-now/index.md absPath of file >>> MarkdownRemark",frontmatter:{date:"2013-11-07T11:21:39Z",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"}},next:{html:'\n
It has been said that "the whole is greater than the sum of its parts"1. Building websites these days is an ever more complicated process. One that requires knowledge of a variety of technologies and techniques. Especially if you want to build websites that can be viewed in a meaningful and useful way on an increasingly large device landscape. Our job as web developers is to find the right combination of these tools and use them wisely. Hopefully the end result is an optimal experience that delivers more than would have been possible without them.
\nBelow you will find a list of some of the technologies and techniques used to build this website. I\'ll write up in depth articles on each of these topics later and link to them from here.
\nI\'ll keep this post updated with any further additions/changes to the website as and when.
\n',id:"/home/geoff/www/cornerpiece/geoffford.co.uk/src/pages/blog/03-11-2013-the-sum-of-its-parts/index.md absPath of file >>> MarkdownRemark",frontmatter:{date:"2013-11-03T00:43:42Z",path:"/blog/the-sum-of-its-parts",title:"The sum of its parts"}}}}}}); //# sourceMappingURL=path---blog-git-cheat-sheet-06459bead4bd1cfd7110.js.map