Git 工作流程 - 版本管理、远程协作和 svn 转换
Git is an extremely powerful source control system. Its power lies in its speed and flexibility, but this can also be a point of confusion for many new users. Git is unfortunately quite inconsistent in its syntax, and exposes many of its not-so-friendly internals to the outside world, sometimes to the detriment of usability.
As many systems built by hardcore engineers (Git came from Linux kernel hackers), if wielded by a wizard, it can be used to achieve many great things, but can be initially confusing even for seasoned developers. This book bypasses the ugly internals of git and gets to the heart of improving your development workflows by using git.
If you've picked up this book, it's likely you're already convinced that git is great. For a great overview, check out http://whygitisbetterthanx.com. To sum it up, the following are my favorite features of git, which this book will focus on.
Git encourages multitasking and experimentation. Fast and easy local branching means the ability to keep bugs and features you're working on in different workspaces, and to experiment more with throwaway branches. Having everything local means you can have fast diffs and history logs, and commit to your repo while on the go without being online.
The ability to pull down other people's changesets for code review and collaboration is made easy with git's multiple remotes capability. Being able to create cheap local branches and experiment with integrating other developer's changesets makes it ideal for open source projects and outsourced collaboration with junior developers, where you want to review other people's code before it becomes part of the master branch. And because anyone who has access to a repo can clone it, they can do development on a fork without asking for your approval, which also encourages experimentation.
How many times have you tried to trace down a feature across many commits, or even worse, tease apart changesets that are clusters of unrelated features? Git offers multiple ways to keep changesets clean, from the index/staging area, to topic branches, to amending commits and completely rewriting your commit history. It's amazing what clean changesets can do to save you time in code review and release management.
Many git books explain git from the bottom up, starting with its internals. Although git sometimes has many ways of doing the same thing, this book will ignore some of the more obscure or advanced features of git in favor of using a basic set of tools to get things done. It's an opinionated book, offering you my own view on how things should be done based on my experiences with git.
Many newcomers to git make the mistake of not taking the time to understand what git does, treating git like their old centralized source control system, and getting frustrated by the number of commands they have to remember to work with new concepts like the index (staging area), their local repo, and remote repos.
If you create a model in your head of what git is doing, you'll be quickly on your way to mastery. Understanding what's happening under the hood relieves you of the burden of having to memorize commands that seemingly make no sense at the outset. It's like understanding how a formula is derived instead of memorizing the formula. Once you understand the model, it will become second nature to work with the various parts of your git repository.
If you are new to git, I highly urge you to read at least one of the following resources:
As the Peepcode book says, "Git != Subversion + Magic!". This is an important mantra that everyone reading this book should understand. Commit some time to learning what git does, and you will be rewarded. However, if you do decide to bypass the intro books, this book will give you enough of an overview so that you can dive right in. It will also provide you with a handy list of aliases making certain features of git easier to work with.
There are also many great cheatsheets availble on the web including:
Chapter 1 will start with a brief review of how a git repository is structured. You'll also get your git environment set up with some enhancements to your bash prompt, and be given a simplified git alias list that will help you work with git on a daily basis without remembering obscure command line switches.
Chapter 2 will teach you to treat your changesets like you do your code, by keeping them clean, cohesive, and refactoring them when needed. You'll learn to use topic branches as workspaces to work on multiple features or bugs, and to combine or tease apart changes to keep patch history clean.
Chapter 3 shows you how to use your repository history to jump back and forth between different commit states, revert changes, and search the repository for commits.
Chapter 4 talks about remote collaboration and code review. You'll learn about remote branches, using GitHub and its forking system, and doing remote pair programming by sharing your branches with your team.
Chapter 5 focuses on release management including tagging, branching, and cherry picking commits between dev and release branches.
Chapter 6 is about introducing git into your organization through an unobtrusive bottom-up process, and using git while everyone else is using subversion.
If you're familiar with subversion, you're used to one central repository, which everyone interacts with by pulling and pushing changes. While you can use git in this way (something we'll talk about in Chapter 3), there are many fundamental differences to understand.
With git you always have the entire repository in your hands, including all its history, branches, and tags. A git project starts in one of two ways. Either you create the repo locally using git init, or you start working on someone else's existing project by using git clone [repo url].
Let's examine the three basic components of a git project tree:
The basic unit that git works with is the changeset (also called a patch). Almost all git commands have to do with operations on changesets, not on files. Keep this in mind if coming from a subversion background. Every git changeset is identified by a SHA-1 hash which looks like this: c15724ef2b99852564a92f9d90c93f9cb6e037ff. The hash is a unique reference to a particular set of changes on a particular branch, and is unique across your repository. Most of the time the first five or so characters of the hash are unique enough to identify it. So you'll sometimes see people abbreviate changeset id's by giving you just the short hash.
Unlike subversion, which litters every directory in your tree with its metadata files, the entire git repo lives in one directory called .git at the top level of your project. Without going into too much detail, this directory contains a list of objects which are binary representations of your changesets, and a list of refs which are the human names you use to refer to your branches and tags. I recommend poking around the .git directory to see what's inside. Most of it is human readable and very educational.
If you've just started or cloned a git project, you'll find you typically have a branch called master. There is nothing special about this branch other than it's the conventional way to name the main development branch — the rough equivalent of trunk in subversion. Git branches are nothing more than human names for a particular changeset. To verify this, just take a look at the file .git/refs/heads/master. Inside, you'll see the hash that identifies the latest commit in your repository on the master branch.
The working tree is the set of files you're currently working with. To start working on something in your git project, you first checkout a particular branch from your repository. When you checkout code, you specify the name of a branch you'd like to work with, and the files in your working tree are replaced with the files from the branch. The files in your working tree are literally overwritten by your checkout – but not to worry. Git will not let you do something stupid like overwrite your changes with a checkout. If your working tree is dirty, git will warn you that checking out a particular branch will overwrite your changes and prevent you from doing so. We'll talk about how to deal with this later.
There is a place interchangeably known as the index, cache, or staging area. This is where you put your changes before they are ready to be comitted to the repository. You'll learn more about the index in Chapter 2, but for now just think of the index as a place that lets you selectively commit changes you make. For example, if you've made a set of file modifications, but it turns out they are two unrelated changes, you can add the appropriate half first to the index, make the commit, and then add the second half and make another commit.
A great image of the git workflow and all the parts of the repo is at :
For more introduction to how git works, please see PeepCode's Git Internals book.
An excellent environment is the first step to enjoying a new tool. Below are several modifications I recommend to a default git setup in order to increase its usability. This chapter explains each modification and alias, but if you'd rather just grab the entire file, it's available in Appendix A.
So that you don't have to type out branch names and other things, locate the file git-completion.bash and add it to your startup scripts so that it executes. This typically involves adding a line to ~/.bashrc:
. /path/to/git-completion.bash
If you can't locate the file, try downloading git-completion.bash
It's very helpful to know which branch you're on at any given time to prevent mistakes. Simply place the following code in your .bashrc and enjoy. Here I've supplied the prompt line (PS1) from my own terminal, but feel free to modify yours as you see fit, inserting the call to $(__git_ps1) wherever you want the branch to appear.
export PS1='[33[01;34m]u:[33[01;32m]w[33[00;34m][33[01;32m][33[00m][33[01;33m]$(__git_ps1)$ [33[00;37m]'
via asemanfar.com
Now, let's make a couple modifications to our ~/.gitconfig to enhance the git experience.
It's important to make working with git easy on the eyes. Turn on colors to see diffs, status, branches, etc in color.
[color]
diff = auto
status = auto
branch = auto
interactive = auto
ui = auto
Git needs periodic maintenance to make it run fast. Here's a way to avoid ever having to think about it by making it run automatically.
[gc]
auto=1
By default, when you merge a branch in git, you get a fairly meaningless message like merge branch 'master' of [email protected]:name/project. To get a summary of the changes you're merging, turn this option on:
[merge]
summary=true
It's also handy when doing cherry-pick to copy changes from one branch to another, to have git automatically put the original commit hash into the commit comment. Here's an alias for doing this:
[alias]
cp = cherry-pick -x
By default, the git branch, remote, and tag commands give you lists
暂无开放 Issues，或尚未同步最近议题。