Tag: git

I have a things-as-code project that outputs mostly text-based formats, but a lot of them. To keep an eye on consistency, I rebuild all the outputs and dump them into a local git repository so I can very easily diff to spot any changes - which was fine until we added a build timestamp, so every file looks changed on every run! This post is about ignoring the matching line with git diff -I.

I consider myself pretty git-confident, I've worked with it a lot, taught it, been a git consultant, run engineering and various things-as-code teams. This week I had a spectactular git problem where merging one branch into another produced changes that didn't exist on either branch. Turns out, renaming directories in a monorepo with multiple almost-identical boilerplate documentation files comes with surprises...

I use a lot of asciidoc these days for work documentation (and I love it) and I've been so happy that GitHub renders it when you view a repository in the web browser, just like it does for Markdown and ReStructuredText. BUT what GitHub does not do is render the image types that asciidoc does so even though I'm working with asciidoc and PlantUML, and the asciidoc tools render those diagrams nicely in PDF and HTML output - GitHub's rendering doesn't. So here's a quick overview of how I handle those repositories.

I read a lot of commit messages that make me wonder who the committer had in mind when they wrote it. If you don't read commit messages yourself, I think that can make it even more difficult to think about who the audience is, or when someone would be reading …

When I teach git I try to show loads of good practice about how to inspect what's staged before commit, etc etc. Good practice is good of course, but knowing how to undo a mess you created is better - and mistakes will happen. For example, accidentally including a node_modules directory in your otherwise excellent and useful commit. This post will walk you through how to fix the problem without losing any of your work.

When chatting about source control good practice the other day, I got a question about repeated git commit messages. In general, I would always advise that the same commit messages appearing multiple times in a project's history is a definite red flag - and if I'm responsible for that repository I will probably make fun of you for doing it.

Examine the diff and comment on it, a line at a time

The scenario: the "main" repository of a git project has changed, either an organisation rebranded, a project got a new maintainer, or a fork became the acknowledged master. In Subversion, this was the svn switch command and git has an equivalent. It's relatively easy in git to change your upstream - once you know how - so don't be tempted to just delete your local repo and re-clone! We can do better than that :)

I'm a fan of submodules in git, but sometimes it seems like I'm the only one! After having worked with this approach on a few projects, I'm coming to the conclusion that, like so many other things, it's easy when you know how! So, I tried to take my handwavy explanation of how to work with submodules, and turn it into a handy diagram for you ...

One of my git repositories has developed a tendency to refuse to checkout a feature branch locally that exists on the remote repo. My git bash completion works, but then strange things happen! It turned out to be that I had two remotes with the same refspec, so I thought I'd write down the behaviour I saw and hopefully help someone else to fix this problem faster if they see it.

I'm very excited to announce that some of my content is featured in the PHP Learning Path from O'Reilly. The Learning Paths are a good way to buy a bundle of content from different people on related topics, and the introductory pricing is always a good deal! Their newest offering …

If you type git pull and expect a fast-forward update, but get a merge instead, don't panic! This usually happens when we're collaborating on a branch with other people, and we've made changes on our local version of a branch, and someone else (or the other you, if you use git to sync between multiple dev platforms) has made changes to the remote version of a branch in the meantime. It also happens really frequently in teams where all commits are to the master branch ... yet another reason to have a decent branching strategy.

All that's happened is something like this:

I have a favourite set of switches to git log, but today I wanted to answer the question "You deleted how much code today?" so I thought I'd share how I did that

git log --numstat will show you how many lines were added (first column) and removed (next column …

At the moment I'm working on a tricky project where two similar projects diverged. Very similar things happened to them both, but not quite the same things - and now we're merging the codebases to give us as much common code as possible. All this simply serves to set the scene of exactly what I was doing spending a whole day with large code diffs - I had to look up a few things so I thought I'd capture them while I can remember.

I love hubot and use one in a few different places. One thing I do find though is that I often want to edit or evolve those plugins, and it seems somehow unethical to just hardcode my changes into my own repo. Once I figured out how to wire together a forked repo as a submodule, it became much easier to work with hubots with external plugins, so I thought I'd share my recipe for that.

I came across a git repo recently that output this message with every operation I did:

Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

I was delivering a workshop at the time so I kinda snarled at it and carried …

I'm very pleased to announce the immediate availability of my new book Git Workbook, costing $20 from LeanPub. This is a book that you "do" rather than "read"; it's a series of chapters (30 ish so far) each covering one specific git skill.

Each chapter includes an explanation of the skill in question, followed by a hands-on exercise so that you can work through the skill yourself, and ends with a tickbox so you can keep track of how far through you are. It has quizzes, diagrams, mildly amusing stories, and as many other examples as I could think of that could help anyone to take in this technical topic and understand how to apply the techniques covered.

Submodules are one of the most powerful and most mistrusted features in git, at least in the web development part of the internet where I spend my time. I've seen them go horribly wrong, but I've also had teams adopt submodules and have their development process run much more smoothly as a result - so I thought I'd take a moment out of my day to write down the process (and the gotchas) of development with submodules.

Here's a little demo video that I put together to explain pushing/pulling with multiple remotes and how tracking branches make this easier. It's one of the chapters from my "Git Adventures" talk, but it didn't make it in to the talk in Amsterdam last week since we chose a …

Here's a topic that took me a while to understand in git, and now (I think!) I do, I thought I'd write it all down while I can remember!

Some branches in git (such as your origin/master branch) will usually track the remote branch that they are related to. But what if you want to create a relationship between local and remote branches? Or stop them from tracking? Here's some pointers

I teach git and often have issues with bad projectors where you can't see the colours. Recently I had a setup where even white on black was more or less invisible, but using black text on a white background worked okay. There's lots of documentation on how to turn on …

Today's little-known git feature (or maybe everyone knows but me? I only found this a few months ago) is for quickly switching between branches. Usually I would switch branches with:

git checkout [branchname]

However if you switch from one branch to another and want to switch back again (this happens …

I've had a little flurry of enquiries about training lately, so I thought I'd mention the courses I have coming up, as especially the PHP ones are topics that I don't run public classes on all that often. At the time of writing I have some space on all of these classes:

My current project does periodic releases, we build a few things, then we work on getting a bunch of user feedback and changing/fixing things before we actually release. This means we need to be organised with tags and branches. We're using GitHub for collaboration, including our issue trackers, commits which contribute to an issue have the issue number in the commit message, and when a branch merges in to the main line, we use the "fixes #42" notation to simultaneously close off the issue that it relates to.

This has been working pretty well, and today I got the question "what's new since I last saw this project?" - so I created a changelog. It's rather rough-and-ready but I had fun so I thought I'd share.

Three git courses are coming up in the next few weeks, and a few people have asked me which courses I'm running, so here's a quick roundup (feel free to drop me a line if you need any more detail):

• Dublin, 30th January: Git and GitHub Foundations
• Dublin, 31st January …

git merge-base is this week's favourite git command. I use it to show me in a vimdiff everything that has changed on a particular branch since it was created. This took a little bit of looking around to find how to combine the tools, so I thought I'd write it all down in one place.

Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).

The document goes on to talk about the available tools (git, Hg, SVN) and give a sales pitch for _why_ source control has benefits for an organisation. There are also some action points to follow to implement source control if you haven't already taken the leap, which I hope will help anyone looking to take that step - it's kind of awkward in this day and age to admit that your organisation doesn't have source control, but however this situation arose, hopefully this document wraps up my thoughts on how to find a good way out!

Today I thought I'd share my "cheat sheet" for git - the commands that I use on a day-to-day basis. I've used entirely the command line tools, since those are the same on every platform. GUI tools and IDE plugins are available for git so it is worth taking a look at what is available for the development environment you use.

This article originally appeared in the May 2012 php|architect magazine.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

This post is mostly about a tutorial I will be delivering at PHPNW on October 5th in Manchester, UK, and why I think a tutorial that contains no PHP belongs at a PHP conference

In October, I'll be delivering a tutorial at the mighty PHPNW Conference which contains very little PHP. Why? Because I think, as developers, it's our other professional skills that suffer. As a consultant, I work with lots of different teams, and it is very rare for code to be the problem (and the one time it was, it wasn't the only problem!).

In web development, our biggest challenges are not writing code, we can do that. But getting the code safely from one place to another, with many people's work preserved, having our platform(s) correctly configured and understanding how to use them, making use of the tools in the ecosystem which will help us improve the quality of our code; these are the big challenges we face, and that's why I proposed this workshop and why I think all these topics are important.

I'm delighted to announce that the nice people over at CakePHP have very kindly invited me to speak at their event in Manchester in September - CakeFest! They brought this event to Manchester last year and I wasn't able to make it, so I'm super-excited to be there this year.

One project I'm working on at the moment involves finding my way around changes in a codebase that isn't mine - and it's quite large. I was doing pretty well with a combination of git log and git show and in particular two of my favourite existing tricks:

Just a quick tip because I'm working on a different git workflow at the moment with one of my clients, and it struck me that this usage pattern is something I don't usually write or speak about at all. Most git setups have one "main" repository, and either:

• there is a gatekeeper that manages merging to here

• all developers have write access

In this case, I'm working with the second option, so I'm pushing to the upstream repo. I'm also pushing to a live repository as well, so I thought I'd outline the commands I'm using. The setup here is the main github repo, and I have my own fork of that, which is cloned onto my laptop. I can push to both that main repo, which I'll call "upstream" (because the github documentation does and it makes sense!) and another repo that I'll call "live". All in all it looks something like this:

Someone emailed me recently, having read my book and wanting some advice. Here's a snippet of his email:

So here's my problem.

We dont know deployment. We work from same copy on one test server through ftp and then upload live on FTP.

We have some small projects and some big collaborative projects.

We host all these projects on our local shared computer which we call test server.

All guys take code from it and return it there. We show our work to clients on that machine and then upload that work to live ftp.

Do you think this is a good scenario or do we make this machine a dev server and introduce a staging server for some projects as well?