Git in Practice
Git in Practice is a collection of 66 tested techniques that will optimize the way you and your team manage your development projects. The book begins with a brief reminder of the core version control concepts you need when using Git and moves on to the high-value features you may not have explored yet. Then, you'll dig into cookbook-style techniques like history visualization, advanced branching and rewriting history each presented in a problem-solution-discussion format. Finally you'll work out how to use Git to its full potential through configuration, team workflows, submodules and using GitHub pull requests effectively.
Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.
About the Technology
Git is a source control system, but it's a lot more than just that. For teams working in today's agile, continuous delivery environments, Git is a strategic advantage. Built with a decentralized structure that's perfect for a distributed team, Git manages branching, committing, complex merges, and task switching with minimal ceremony so you can concentrate on your code.
About the Book
Git in Practice is a collection of battle-tested techniques designed to optimize the way you and your team manage development projects. After a brief overview of Git's core features, this practical guide moves quickly to high-value topics like history visualization, advanced branching and rewriting, optimized configuration, team workflows, submodules, and how to use GitHub pull requests. Written in an easy-to-follow Problem/Solution/Discussion format with numerous diagrams and examples, it skips the theory and gets right to the nitty-gritty tasks that will transform the way you work.
Written for developers familiar with version control and ready for the good stuff in Git.
- Team interaction strategies and techniques
- Replacing bad habits with good practices
- Juggling complex configurations
- Rewriting history and disaster recovery
About the Author
Mike McQuaid is a software engineer at GitHub. He's contributed to Qt and the Linux kernel, and he maintains the Git-based Homebrew project.
Table of Contents
- Local Git
- Remote Git
- Filesystem interactions
- History visualization
- Advanced branching
- Rewriting history and disaster recovery
- Personalizing Git
- Vendoring dependencies as submodules
- Working with Subversion
- GitHub pull requests
- Hosting a repository
- Creating a clean history
- Merging vs. rebasing
- Recommended team workflows
PART 1 INTRODUCTION TO GIT
PART 2 GIT ESSENTIALS
PART 3 ADVANCED GIT
PART 4 GIT BEST PRACTICES
final state. Figure 1.9 shows a fairly common use case for rewriting history with Git. If you were working on some window code all morning and wanted your coworkers to see it later (or wanted to include it in the project), there’s no need for everyone to see the mistakes you made along the way. In the figure the commits are squashed together: so instead of having three commits with the latter two fixing mistakes from the first commit, we’ve squashed them together to create a single commit for the
useful, so let’s learn how to do that. Technique 5 Viewing the differences between commits: git diff A diff (also known as a change or delta) is the difference between two commits. In Git you can request a diff between any two commits, branches, or tags. It’s often useful to be able to request the difference between two parts of the history for analysis. For example, if an unexpected part of the software has recently started misbehaving, you can go back into the history to verify that it
tools, such as Subversion, if you don’t have commit access to a repository, the best attribution you could hope for would be something like “Thanks to Mike McQuaid for this commit!” in the commit message. In Subversion the equivalent git blame command is svn blame. It also has an alias called svn praise. In Git there’s no such alias by default (but technique 50 will later show you how to create one yourself). I’m sure there’s a joke to be made about the fact that Subversion offers praise and
*.asciidoc*. When the .asciidoc file is named GitInPractice.asciidoc, run git bisect good to indicate that the file hasn’t been renamed yet. When the .asciidoc file is named 01-IntroducingGitInPractice.asciidoc, run git bisect bad to indicate that the file has been renamed. The output should be similar each time. No other parameters are required to git bisect good or git bisect bad; they automatically check out the next revision to be checked when they’re run. Eventually the first bad commit will
tags in the repository. Solution 1 2 Change to the directory containing your repository: for example, cd /Users/mike/GitInPracticeRedux/. Run git describe --tags. The output should resemble the following. Listing 5.15 Output: tag describe # git describe --tags v0.1-1-g0a5e328 B Generated version B shows the version generated from the state based on existing tags. It’s hyphenated into three parts: v0.1 is the most recent tag on the current branch. 1 indicates that one commit has been