1. Learn Git
    1. Learn Git with Bitbucket Cloud
      1. Create a Git repository
      2. Copy your Git repository and add files
      3. Pull changes from your Git repository on Bitbucket Cloud
      4. Use a Git branch to merge a file
    2. Learn about code review in Bitbucket Cloud
      1. Fork a teammate's repository
      2. Copy your fork and make a change to the repository
      3. Create a pull request
  2. Getting Started
    1. What is version control
      1. Benefits of version control
    2. What is Git
      1. Performance
      2. Security
      3. Flexibility
      4. Version control with Git
    3. Why Git for your organization
      1. Git for developers
      2. Git for marketing
      3. Git for product management
      4. Git for designers
      5. Git for customer support
      6. Git for human resources
      7. Git for anyone managing a budget
    4. Install Git
      1. Install Git on Mac OS X
      2. Install Git on Windows
      3. Install Git on Linux
    5. Setting up a repository
      1. git init
      2. git clone
      3. git config
    6. Saving changes
      1. git add
      2. git commit
    7. Git Stash
      1. .gitignore
        1. Inspecting a repository
          1. git status
          2. git log
        2. Viewing old commits
          1. Undoing Changes
            1. git checkout
            2. git revert
            3. git reset
            4. git clean
          2. Rewriting history
            1. git commit --amend
            2. git rebase
            3. git rebase -i
            4. git reflog
        3. Collaborating
          1. Syncing
            1. git remote
            2. git fetch
            3. git pull
            4. git push
          2. Making a Pull Request
            1. How it works
            2. Example
            3. Where to go from here
          3. Using Branches
            1. git branch
            2. git checkout
            3. git merge
          4. Comparing Workflows
            1. Centralized Workflow
            2. Feature Branch Workflow
            3. Gitflow Workflow
            4. Forking Workflow
        4. Migrating to Git
          1. SVN to Git - prepping for the migration
            1. For administrators
            2. Basic Git commands
            3. Git Migration Tools
            4. For developers
          2. Migrate to Git from SVN
            1. Prepare
              1. Convert
                1. Synchronize
                  1. Share
                    1. Migrate
                      1. Perforce to Git - why to make the move
                        1. Migrating from Perforce to Git
                        2. Advanced Tips
                          1. Advanced Git Tutorials
                            1. Merging vs. Rebasing
                              1. Conceptual Overview
                              2. The Golden Rule of Rebasing
                              3. Workflow Walkthrough
                              4. Summary
                            2. Reset, Checkout, and Revert
                              1. Commit-level Operation
                              2. File-level Operations
                              3. Summary
                            3. Advanced Git log
                              1. Formatting Log Output
                              2. Filtering the Commit History
                              3. Summary
                            4. Git Hooks
                              1. Conceptual Overview
                              2. Local Hooks
                              3. Server-side Hooks
                              4. Summary
                            5. Refs and the Reflog
                              1. Hashes
                              2. Refs
                              3. Packed Refs
                              4. Special Refs
                              5. Refspecs
                              6. Relative Refs
                              7. The Reflog
                              8. Summary
                            6. Git LFS

                            Git guilt, blame, and code review

                            Tim PettersonTim Petterson
                            Back to list

                            I've been doing a bit of traveling lately on the second leg of the Getting Git Right tour. It's been a blast meeting so many devs from around the world. It's been particularly incredible to see how much git adoption has grown amongst attendees in the few months since we did the first leg of the tour. When we presented in July, almost all attendees raised their hand when we asked "Who's using git?".

                            However, there is one low point during every evening that I've hosted: the moment after I ask the question "Who's doing code review at work?"

                            Typically less than half the audience sticks up their hand.

                            This makes me sad, because code review has been incredibly valuable to me during my career. In fact, I would recommend code review over any other practice or technology as the single most effective way to incrementally increase the quality of any given codebase. And the DVCS implementation of code review - the pull request - is a particularly amazing tool.

                            Here's my top 3 reasons why:

                            Better code

                            The first reason is pretty obvious: having developers with different levels of experience, different technical specializations, and different perspectives grokking your code means you have a far higher chance of catching bugs and stemming technical debt – before your code reaches your customers. If you're using pull requests, these issues are caught before your code even hits the main branch, so issues caught in review impact nobody at all. This means that the quality of your codebase and the product that you're shipping goes way up.

                            Knowledge sharing

                            The second reason is a bit more subtle. Those developers that are reviewing your code aren't just providing you a free service with no benefit to themselves – they're learning too! As a junior developer, sitting on code reviews taught me more about software patterns and libraries than any book that I've read or presentation that I've attended. As a senior developer, code reviews have unlocked a lot of tribal knowledge that is specific to a particular software project or team. Each application has its own stack, patterns, and idiosyncrasies that shape the best way to patch a bug or implement a feature. Code review does a really good job at spreading this information around the team.

                            Communal ownership

                            The third reason is the most overlooked, but arguably one of the most important for the long term health of your product. If you're a developer, you've probably shipped a bug to a customer at some point. It is a terrible feeling. You see the bug report pop up in JIRA during a triage session, you read the oddly-familiar description with a sinking feeling and realize that the code that you authored and shipped is causing a customer (probably multiple customers) a world of pain.

                            However - and this is a dirty little secret - if you're doing code review as part of your development process, that bug is not your fault! At least, not just your fault. The formula for developer guilt looks like this:

                            g = 1 / n + 1

                            If n developers signed off on the review, you only feel 1 / n + 1 the shame when you ship a bug.

                            I am (sort of) kidding. But more practically speaking, if n developers have signed off on a review, then you have n developers who can jump in and fix the bug if the original author has left the company / is asleep in another timezone / whatever, while you have customers wide awake and screaming down the phone or on your issue tracker.

                            So those are the three top reasons why I think code review is good practice for a team of any size greater than one. This segues nicely into the main reason I'm writing this blog post! I recently released a little tool for making code review (with git) an easier process.

                            One of the tricky parts of creating a pull request is determining the perfect set of people to review your code. Sometimes it's obvious. If you work on a small team or you've been on the same team for a while, you know who the relevant domain expert is for the part of the codebase you've modified. But if you're new to a team, work with a large number of people or are contributing to a project outside of your regular work, the decision may be a little trickier.

                            Introducing.. git-guilt

                            git-guilt is a little tool I wrote that lets you see the transfer of blame in a repository caused by a range of commits. For example, if you wanted to see how blame shifted from one author to another during your last commit, you can run the command:

                            git guilt HEAD~1

                            Terminal — bash — 98×28 2014-07-17 18-17-48 2014-07-17 18-49-07

                            The output indicates that in my last commit I added 239 lines of code, at the same time removing 2 lines previously attributed to Patrick, 5 lines from Seb, 13 lines from Anders and a whole bunch of lines from JD. This is kind of fun if you're competitive by nature, but more practically speaking the developers that appear in the output are a good candidates to review the pull request that I'll create to merge these changes back to the master branch.

                            The logic behind this is that the developers whose code you're rewriting may have something to say about the matter. ;)

                            git-guilt is named so because it shows the transfer of blame (or guilt) of a codebase between commits. Like other commands in the git suite, it can take any commit or ref as an argument. For example, using the merge-base command to determine the branch point, you can show the blame of an entire feature branch like this:

                            git guilt `git merge-base master my-feature-branch` my-feature-branch

                            Terminal — bash — 134×43 2014-07-18 14-07-08 2014-07-18 14-07-11

                            Or the blame change over a period of time:

                            git guilt `git log --until="3 days ago" --format="%H" -n 1

                            Terminal — bash — 134×43 2014-07-18 14-11-00 2014-07-18 14-11-01


                            git-guilt is packaged as an npm module, so installation is easy if you want to give it a whirl:

                            • Make sure you have Git, Node.js and npm installed
                            • Run npm install -g git-guilt (you may need sudo)
                            • Run git-guilt HEAD~1 in any git repository to see the blame delta for the most recent commit. You can also easily install it as a post-commit hook, to show the live transfer of code blame as you create new commits locally. Just echo the following to .git/hooks/post-commit:
                            git guilt HEAD~1

                            and make sure the file is executable:

                            chmod a+x .git/hooks/post-commit

                            The next time you commit you'll see the git-guilt output showing how the blame has changed.


                            The source is up on Bitbucket if you'd like to peruse or contribute.

                            Bitbucket Server fan?

                            If you find this useful and you're using Bitbucket Server for git hosting, you may enjoy the free Bitbucket Server Reviewer Suggester add-on that I built for a ShipIt competition a while back. It implements a similar algorithm for suggesting reviewers (with a couple of embellishments) and is nicely integrated in the Bitbucket Server Pull Request creation UI.

                            P.S. I'm serious

                            If you're one of the 50% of developers that reads this that aren't practicing code review, start today. You won't regret it! You could have caught a bug (and saved multiple customers pain) and learnt various new things about your codebase in less time than it took to read this blog post. :)