You'd like to find the earliest tagged release that contains that. Of course, there may be more than one answer--if the history branched. You could just visually inspect the commits since e05db0fd:. The linkgit:git-describe[1] command does the opposite, naming the. If you just want to verify whether a given tagged version contains a. The merge-base command finds a common ancestor of the given commits,. As yet another alternative, the linkgit:git-show-branch[1] command lists.
Suppose you would like to see all the commits reachable from the branch. We can list all the heads in this repository with. And then we can ask to see all the commits reachable from master. Obviously, endless variations are possible; for example, to see all. See linkgit:gitrevisions[7] for explanations of commit-selecting. The linkgit:git-archive[1] command can create a tar or zip archive from. The output file format is inferred from. Versions of Git older than 1.
If you're releasing a new version of a software project, you may want. Linus Torvalds, for example, makes new kernel releases by tagging them,. Somebody hands you a copy of a file, and asks which commits modified a. Figuring out why this works is left as an exercise to the advanced.
The linkgit:git-log[1], linkgit:git-diff-tree[1], and. Before creating any commits, you should introduce yourself to Git. The easiest way to do so is to use linkgit:git-config[1]:. The file is plain text, so you can. Creating a new repository from scratch is very easy:.
If you have some initial content say, a tarball :. Creating a new commit takes three steps:. Making some changes to the working directory using your. Creating the commit using the content you told Git about.
In practice, you can interleave and repeat steps 1 and 2 as many. At the beginning, the content of the index will be identical to. To update the index with the contents of a new or modified file, use.
To remove a file from the index and from the working tree, use. Check to make sure it looks like what you expected with. A number of commands are useful for keeping track of what you're. You can also use linkgit:git-gui[1] to create commits, view changes in.
Though not required, it's a good idea to begin the commit message. The text up to the first blank line in a commit. For example, linkgit:git-format-patch[1] turns a. A project will often generate files that you do 'not' want to track with Git.
This typically includes files generated by a build process or temporary. Of course, 'not' tracking files with Git. But it quickly becomes. You can tell Git to ignore certain files by creating a file called.
Lines starting with ' ' are considered comments. See linkgit:gitignore[5] for a detailed explanation of the syntax. You can. If you wish the exclude patterns to affect only certain repositories. Some Git commands can also take exclude patterns directly on the. See linkgit:gitignore[5] for the details. You can rejoin two diverging branches of development using.
The work tree is overwritten by the result of. Therefore, if you have uncommitted changes touching the same files as. Most of. If the changes are independent enough, Git will automatically complete. On the other hand,. Automatic merge failed; fix conflicts and then commit the result. Conflict markers are left in the problematic files, and after. If you examine the resulting commit using gitk, you will see that it. When a merge isn't resolved automatically, Git leaves the index and.
Files with conflicts are marked specially in the index, so until you. Also, linkgit:git-status[1] will list those files as "unmerged", and the. All you need to do is edit the files to resolve the conflicts, and then.
Note that the commit message will already be filled in for you with. Normally you can just use this. The above is all you need to know to resolve a simple merge. But Git. All of the changes that Git was able to merge automatically are. It uses an unusual syntax:. Recall that the commit which will be committed after we resolve this.
During the merge, the index holds three versions of each file. Each of. When you ask linkgit:git-diff[1] to show the conflicts, it runs a. Same for stage 3. The diff above shows the differences between the working-tree version of. So instead of preceding. After resolving the conflict in the obvious way but before updating the. This shows that our resolved version deleted "Hello world" from the. Some special diff options allow diffing the working directory against. The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help.
These will display all commits which exist only on HEAD or on. You may also use linkgit:git-mergetool[1], which lets you merge the. Each time you resolve the conflicts in a file and update the index:. If you get stuck and decide to just give up and throw the whole mess. Or, if you've already committed the merge that you want to throw away,.
However, this last command can be dangerous in some cases--never. There is one special case not mentioned above, which is treated. Normally, a merge results in a merge commit, with two. However, if the current branch is an ancestor of the other--so every commit. If you've messed up the working tree, but haven't yet committed your. If you make a commit that you later wish you hadn't, there are two. You can create a new commit that undoes whatever was done. This is the correct thing if your.
You can go back and modify the old commit. You should. Git does not normally expect the "history" of a project to. Creating a new commit that reverts an earlier change is very easy;. This will create a new commit which undoes the change in HEAD. You can also revert an earlier change, for example, the next-to-last:. In this case Git will attempt to undo the old change while leaving.
If more recent changes overlap. If the problematic commit is the most recent commit, and you have not. Again, you should never do this to a commit that may already have. It is also possible to replace commits further back in the history, but. In the process of undoing a previous bad change, you may find it. It does not change branches. If you just want to look at an old version of the file, without. While you are in the middle of working on something complicated, you.
You would like to fix it. You can use linkgit:git-stash[1] to save the current. Then you can make your fix as usual. After that, you can go back to what you were working on with. On large repositories, Git depends on compression to keep the history. Git commands may automatically run linkgit:git-gc[1], so you don't. However, compressing a large. The linkgit:git-fsck[1] command runs a number of self-consistency checks.
This may take some. You will see informational messages on dangling objects. They are objects. Fortunately, Git also keeps a log, called a "reflog", of all the. So in this case you can still find the. This lists the commits reachable from the previous version of the. This syntax can be used with any Git command. Some other examples:. A separate reflog is kept for the HEAD, so.
This allows you to see the history of what. The reflogs are kept by default for 30 days, after which they may be. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn. Note that the reflog history is very different from normal Git history. While normal history is shared by every repository that works on the. In some situations the reflog may not be able to save you.
The reflog is also deleted; however, if you have not yet. And notice that it might not be just one commit: we only report the. If you decide you want the history back, you can always create a new. Other types of dangling objects blobs and trees are also possible, and. So you can merge in changes from the. However, the linkgit:git-pull[1] command provides a way to do this in. This command will fetch changes from the remote branches to your.
More generally, a branch that is created from a remote-tracking branch. See the descriptions of the. But note that no such commit will be created in the case of a. If you just have a few changes, the simplest way to submit them may. First, use linkgit:git-format-patch[1]; for example:. You can insert. You can then import these into your mail client and send them by. However, if you have a lot to send at once, you may prefer to.
Consult the mailing list for your project first to determine. Git also provides a tool called linkgit:git-am[1] am stands for. Just save all of the patch-containing messages, in order, into a. Git will apply each patch in order; if any conflicts are found, it. Git to perform a merge; if you would prefer it just to abort and.
Once the index is updated with the results of the conflict. The final result will be a series of commits, one for each patch in. Another way to submit changes to a project is to tell the maintainer. If you and the maintainer both have accounts on the same machine, then. For projects with few developers, or for synchronizing a few private. However, the more common way to do this is to maintain a separate public. This is usually more convenient, and allows you to cleanly.
You will continue to do your day-to-day work in your personal. So the flow of changes, in a situation. We explain how to do this in the following sections. The resulting directory proj.
You can use scp, rsync, or whatever is most. If someone else administers the server, they should tell you what. You can then skip to the section. Otherwise, all you need to do is start linkgit:git-daemon[1]; it will. By default, it will allow access to any directory. See especially the. The Git protocol gives better performance and reliability, but on a. All you need to do is place the newly created bare Git repository in. For an explanation of the last two lines, see. Anybody else should then be able to.
Note that the two techniques outlined above exporting via. The simplest way to do this is using linkgit:git-push[1] and ssh; to. You can also push to a. See the description of the receive. Integrate the remote changes e. This can happen, for example, if you:. Alternatively, you can use the. Normally whenever a branch head in a public repository is modified, it.
By forcing a push in this situation, you break that convention. Nevertheless, this is a common practice for people that need a simple.
It's also possible for a push to fail in this way when other people have. In that case, the correct. Another way to collaborate is by using a model similar to that. However, while there is nothing wrong with Git's support for shared. The gitweb cgi script provides users an easy way to browse your. The linkgit:git-instaweb[1] command provides a simple way to start. The default server when using. The depth can later be.
Otherwise, it will be like merging unrelated histories and may. This limitation may make such. This describes how Tony Luck uses Git in his role as maintainer of the. IA64 architecture for the Linux kernel. This tree is available to Andrew for pulling into -mm whenever he. He also uses a set of temporary branches "topic branches" , each.
To set this up, first create your work tree by cloning Linus's public. Now create the branches in which you are going to work; these start out. These can be easily kept up to date using linkgit:git-pull[1]. Important note! If you have any local changes in these branches, then. Many people dislike. A few configuration variables see linkgit:git-config[1] can. Then you can push both the test and release trees using.
Now to apply some patches from the community. You update your working directory from the index by "checking out" files. Finally, there are a few odds and ends which are not purely moving from one representation to the other:. Normally a "commit" has one parent: the previous state of the tree before a certain change was made. However, sometimes it can have two or more parent commits, in which case we call it a "merge", due to the fact that such a commit brings together "merges" two or more previous states represented by other commits.
In other words, while a "tree" represents a particular directory state of a working directory, a "commit" represents that state in time, and explains how we got there. You create a commit object by giving it the tree that describes the state at the time of the commit, and a list of parents:. You can examine the data represented in the object database and the index with various helper tools. For every object, you can use git-cat-file[1] to examine details about the object:.
Trees have binary content, and as a result there is a special helper for showing that content, called git ls-tree , which turns the binary content into a more easily readable form. In particular, if you follow the convention of having the top commit name in. Git can help you perform a three-way merge, which can in turn be used for a many-way merge by repeating the merge procedure several times. The usual situation is that you only do one three-way merge reconciling two lines of history and commit the result, but if you like to, you can merge several branches in one go.
To perform a three-way merge, you start with the two commits you want to merge, find their closest common parent a third commit , and compare the trees corresponding to these three commits. This prints the name of a commit they are both based on. You should now look up the tree objects of those commits, which you can easily do with. Once you know the three trees you are going to merge the one "original" tree, aka the common tree, and the two "result" trees, aka the branches you want to merge , you do a "merge" read into the index.
If there are files that have been added, moved or removed, or if both branches have modified the same file, you will be left with an index tree that contains "merge entries" in it.
Such an index tree can NOT be written out to a tree object, and you will have to resolve any such merge clashes using other tools before you can write out the result.
Each line of the git ls-files --unmerged output begins with the blob mode bits, blob SHA-1, stage number , and the filename. Earlier we said that trivial merges are done inside git read-tree -m. What the above example shows is that file hello. You could resolve this by running your favorite 3-way merge program, e. This would leave the merge result in hello.
After verifying the merge result makes sense, you can tell Git what the final merge result for this file is by:. When a path is in the "unmerged" state, running git update-index for that path tells Git to mark the path resolved. The above is the description of a Git merge at the lowest level, to help you understand what conceptually happens under the hood. In practice, nobody, not even Git itself, runs git cat-file three times for this.
There is a git merge-index program that extracts the stages to temporary files and calls a "merge" script on it:. This chapter covers internal details of the Git implementation which probably only Git developers need to understand.
All objects have a statically determined "type" which identifies the format of the object i. There are currently four different object types: "blob", "tree", "commit", and "tag". Regardless of object type, all objects share the following characteristics: they are all deflated with zlib, and have a header that not only specifies their type, but also provides size information about the data in the object.
The structured objects can further have their structure and connectivity to other objects verified. This is generally done with the git fsck program, which generates a full dependency graph of all objects, and verifies their internal consistency in addition to just verifying their superficial consistency through the hash. This section gives you a little guidance to show where to start. The initial revision lays the foundation for almost everything Git has today, but is small enough to read in one sitting.
Note that terminology has changed since that revision. Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.
If you grasp the ideas in that initial commit, you should check out a more recent version and skim cache. In the early days, Git in the tradition of UNIX was a bunch of programs which were extremely simple, and which you used in scripts, piping the output of one into another. This turned out to be good for initial development, since it was easier to test new things. However, recently many of these parts have become builtins, and some of the core has been "libified", i.
By now, you know what the index is and find the corresponding data structures in cache. Next step: get familiar with the object naming. Read Naming commits. There are quite a few ways to name an object and not only revisions! It is still functional, and needs to, since most new Git commands start out as scripts using git rev-list. Most of what git rev-list did is contained in revision. Nowadays, git log is a builtin, which means that it is contained in the command git.
The source side of a builtin is. Sometimes, more than one builtin is contained in one source file. In that case, the commands which are not named like the. Lesson three is: study the code. Really, it is the best way to learn about the organization of Git after you know the basic concepts.
So, think about something which you are interested in, say, "how can I access a blob just knowing the object name of it? The first step is to find a Git command with which you can do it.
In this example, it is either git show or git cat-file. It tries to interpret argv[2] as an object name, and if it refers to an object which is present in the current repository, it writes the resulting SHA-1 into the variable sha1. This variable will contain the bit SHA-1 of the given commit. This is how you read a blob actually, not only a blob, but any type of object. Sometimes, you do not know where to look for a feature.
In many such cases, it helps to search through the output of git log , and then git show the corresponding commit. In the pager less , just search for "bundle", go a few lines back, and see that it is in commit ab0. Now just copy this object name, and paste it into the command line. Via the alternates mechanism, a repository can inherit part of its object database from another object database, which is called an "alternate".
A bare repository is normally an appropriately named directory with a. That is, all of the Git administrative and control files that would normally be present in the hidden. Usually publishers of public repositories make bare repositories available. A "branch" is a line of development.
The most recent commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head , which moves forward as additional development is done on the branch. A single Git repository can track an arbitrary number of branches, but your working tree is associated with just one of them the "current" or "checked out" branch , and HEAD points to that branch.
A list of objects, where each object in the list contains a reference to its successor for example, the successor of a commit could be one of its parents.
Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git. The action of updating all or part of the working tree with a tree object or blob from the object database , and updating the index and HEAD if the whole working tree has been pointed at a new branch.
In SCM jargon, "cherry pick" means to choose a subset of changes out of a series of changes typically commits and record them as a new series of changes on top of a different codebase. In Git, this is performed by the "git cherry-pick" command to extract the change introduced by an existing commit and to record it based on the tip of the current branch as a new commit. A working tree is clean, if it corresponds to the revision referenced by the current head.
Also see " dirty ". As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits.
The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version". Also used as a short hand for commit object. An object which contains the information about a particular revision , such as parents , committer, author, date and the tree object which corresponds to the top directory of the stored revision.
A commit object or an object that can be recursively dereferenced to a commit object. The following are all commit-ishes: a commit object, a tag object that points to a commit object, a tag object that points to a tag object that points to a commit object, etc. Fundamental data structures and utilities of Git. Exposes only limited source code management tools. Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents directed , and the graph of commit objects is acyclic there is no chain which begins and ends with the same object.
An unreachable object which is not reachable even from other unreachable objects; a dangling object has no references to it from any reference or object in the repository. The HEAD in such a state is called "detached". Note that commands that operate on the history of the current branch e. They update the HEAD to point at the tip of the updated history without affecting any branch.
Commands that update or inquire information about the current branch e. A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch.
An evil merge is a merge that introduces changes that do not appear in any parent. A fast-forward is a special type of merge where you have a revision and you are "merging" another branch 's changes that happen to be a descendant of what you have.
In such a case, you do not make a new merge commit but instead just update your branch to point at the same revision as the branch you are merging. This will happen frequently on a remote-tracking branch of a remote repository. See also git-fetch[1]. Linus Torvalds originally designed Git to be a user space file system, i. That ensured the efficiency and speed of Git. A plain file. Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits.
This way you can make Git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the. Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace[1] for a more flexible and robust system to do the same thing.
A named reference to the commit at the tip of a branch. See git-pack-refs[1]. The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the heads in your repository, except when using a detached HEAD , in which case it directly references an arbitrary commit.
During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking.
Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. In earlier versions of Git you had to make them executable.
A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when merging.
The information regarding a particular file, stored in the index. An index entry can be unmerged, if a merge was started, but not yet finished i. The default development branch. Whenever you create a Git repository , a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.
As a verb: To bring the contents of another branch possibly from an external repository into the current branch. In the case where the merged-in branch is from a different repository, this is done by first fetching the remote branch and then merging the result into the current branch.
This combination of fetch and merge operations is called a pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge. As a noun: unless it is a fast-forward , a successful merge results in the creation of a new commit representing the result of the merge, and having as parents the tips of the merged branches.
This commit is referred to as a "merge commit", or sometimes just a "merge". The unit of storage in Git. It is uniquely identified by the SHA-1 of its contents. Consequently, an object cannot be changed. Stores a set of "objects", and an individual object is identified by its object name. The unique identifier of an object. The object name is usually represented by a 40 character hexadecimal string. Also colloquially called SHA One of the identifiers " commit ", " tree ", " tag " or " blob " describing the type of an object.
The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. This is the default mode in a checkout when checking out files from the index or a tree-ish. In contrast, no-overlay mode also deletes tracked files not present in the source, similar to rsync --delete.
A set of objects which have been compressed into one file to save space or to transmit them efficiently. The list of identifiers, and other information, of the objects in a pack , to assist in efficiently accessing the contents of a pack.
Pathspecs are used on the command line of "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or worktree.
See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:. The scope of that pathspec is limited to that subtree. A pathspec that begins with a colon : has special meaning.
In the short form, the leading colon : is followed by zero or more "magic signature" letters which optionally is terminated by another colon : , and the remainder is the pattern to match against the path.
The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon. In the long form, the leading colon : is followed by an open parenthesis , a comma-separated list of zero or more "magic words", and a close parentheses , and the remainder is the pattern to match against the path.
A pathspec with only a colon means "there is no pathspec". This form should not be combined with other pathspec. A slash followed by two consecutive asterisks then a slash matches zero or more directories. After attr: comes a space separated list of "attribute requirements", all of which must be met in order for the path to be considered a match; this is in addition to the usual non-magic pathspec pattern matching.
See gitattributes[5]. Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object. After a path matches any non-exclude pathspec, it will be run through all exclude pathspecs magic signature:! If it matches, the path is ignored. When there is no non-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec.
A commit object contains a possibly empty list of the logical predecessor s in the line of development, i. The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the --pickaxe-all option, it can be used to view the full changeset that introduced or removed, say, a particular line of text. See git-diff[1]. Cute name for programs and program suites depending on core Git , presenting a high level access to core Git.
Porcelains expose more of a SCM interface than the plumbing. Refs that are per- worktree , rather than global. Pseudorefs both have names that are all-caps, and always start with a line consisting of a SHA-1 followed by whitespace. So, HEAD is not a pseudoref, because it is sometimes a symbolic ref. They might optionally contain some additional data. Unlike per-worktree refs , these files cannot be symbolic refs, and never have reflogs. They also cannot be updated through the normal ref update machinery.
Instead, they are updated by directly writing to the files. Pulling a branch means to fetch it and merge it. See also git-pull[1]. If the remote head is not an ancestor to the local head, the push fails. All of the ancestors of a given commit are said to be "reachable" from that commit. More generally, one object is reachable from another if we can reach the one from the other by a chain that follows tags to whatever they tag, commits to their parents or trees, and trees to the trees or blobs that they contain.
To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result. For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository. The ref namespace is hierarchical. Different subhierarchies are used for different purposes e. The most notable example is HEAD. A reflog shows the local "history" of a ref.
In other words, it can tell you what the 3rd last revision in this repository was, and what was the current state in this repository, yesterday pm. See git-reflog[1] for details. A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref.
A repository which is used to track the same project but resides somewhere else. To communicate with remotes, see fetch or push. A ref that is used to follow changes from another repository. A remote-tracking branch should not contain direct modifications or have local commits made to it.
A collection of refs together with an object database containing all objects which are reachable from the refs, possibly accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories via alternates mechanism. The action of fixing up manually what a failed automatic merge left behind. To throw away part of the development, i. In the context of Git used as a synonym for object name. A shallow repository has an incomplete history some of whose commits have parents cauterized away in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object.
This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the --depth option to git-clone[1] , and its history can be later deepened with git-fetch[1]. An object used to temporarily store the contents of a dirty working directory and the index for future reuse.
A repository that holds the history of a separate project inside another repository the latter of which is called superproject. A repository that references repositories of other projects in its working tree as submodules. The superproject knows about the names of but does not hold copies of commit objects of the contained submodules.
HEAD is a prime example of a symref. Symbolic references are manipulated with the git-symbolic-ref[1] command. In contrast to a head , a tag is not updated by the commit command.
A tag is most typically used to mark a particular point in the commit ancestry chain. An object containing a ref pointing to another object, which can contain a message just like a commit object. It can also contain a PGP signature, in which case it is called a "signed tag object". A regular Git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes.
Either a working tree , or a tree object together with the dependent blob and tree objects i. A tree is equivalent to a directory. A tree object or an object that can be recursively dereferenced to a tree object. Dereferencing a commit object yields the tree object corresponding to the revision 's top directory.
The following are all tree-ishes: a commit-ish , a tree object, a tag object that points to a tree object, a tag object that points to a tag object that points to a tree object, etc. An index which contains unmerged index entries.
An object which is not reachable from a branch , tag , or any other reference. The default branch that is merged into the branch in question or the branch in question is rebased onto. It is configured via branch. The tree of actual checked out files. This is a quick summary of the major commands; the previous chapters explain how these work in more detail.
It must be readable in order, from beginning to end, by someone intelligent with a basic grasp of the UNIX command line, but without any special knowledge of Git. If necessary, any other prerequisites should be specifically mentioned as they arise. Whenever possible, section headings should clearly describe the task they explain how to do, in language that requires no more knowledge than necessary: for example, "importing patches into a project" rather than "the git am command".
Think about how to create a clear chapter dependency graph that will allow people to get to important topics without necessarily reading everything in between. Add more good examples. Entire sections of just cookbook examples might be a good idea; maybe make an "advanced examples" section a standard end-of-chapter section?
Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs. More on recovery from repository corruption. Setup and Config git config help bugreport Getting and Creating Projects init clone Basic Snapshotting add status diff commit notes restore reset rm mv Branching and Merging branch checkout switch merge mergetool log stash tag worktree Sharing and Updating Projects fetch pull push remote submodule.
Inspection and Comparison show log diff difftool range-diff shortlog describe Patching apply cherry-pick diff rebase revert Debugging bisect blame grep Email am apply format-patch send-email request-pull External Systems svn fast-import Server Admin daemon update-server-info. Administration clean gc fsck reflog filter-branch instaweb archive bundle Plumbing Commands cat-file check-ignore checkout-index commit-tree count-objects diff-index for-each-ref hash-object ls-files ls-tree merge-base read-tree rev-list rev-parse show-ref symbolic-ref update-index update-ref verify-pack write-tree.
Introduction Git is a fast distributed revision control system. Repositories and Branches How to get a Git repository It will be useful to have a Git repository to experiment with as you read this manual. Git itself approx. How to check out a different version of a project Git is best thought of as a tool for storing the history of a collection of files.
Understanding History: Commits Every change in the history of a project is represented by a commit. As you can see, a commit shows who made the latest change, what they did, and why.
Understanding history: commits, parents, and reachability Every commit except the very first commit in a project also has a parent commit which shows what happened before this commit. Understanding history: History diagrams We will sometimes represent Git history using diagrams like the one below. Understanding history: What is a branch? Examining an old version without creating a new branch The git switch command normally expects a branch head, but will also accept an arbitrary commit when invoked with --detach; for example, you can check out the commit referenced by a tag:.
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another switch. If you want to create a new branch to retain commits you create, you may do so now or later by using -c with the switch command again.
Examining branches from a remote repository The "master" branch that was created at the time you cloned is a copy of the HEAD in the repository that you cloned from. Naming branches, tags, and other references Branches, remote-tracking branches, and tags are all references to commits. The tag v2. Updating a repository with git fetch After you clone a repository and commit a few changes of your own, you may wish to check the original repository for updates.
Fetching branches from other repositories You can also track branches from repositories other than the one you cloned from, using git-remote[1] :. If you examine the file. Exploring Git history Git is best thought of as a tool for storing the history of a collection of files. Git provides extremely flexible and fast tools for exploring the history of a project. How to use bisect to find a regression Suppose version 2. Naming commits We have seen several ways of naming commits already:. HEAD: refers to the head of the current branch.
In addition to HEAD, there are several other special names for commits:. Creating tags We can also create a tag to refer to a particular commit; after running.
Browsing revisions The git-log[1] command can show lists of commits. Generating diffs You can generate diffs between any two versions using git-diff[1] :. Viewing old file versions You can always view an old version of a file by just checking out the correct revision first. Check whether two branches point at the same history Suppose you want to check whether two branches point at the same point in history. Find first tagged version including a given fix Suppose you know that the commit e05db0fd fixed a certain problem.
Showing commits unique to a given branch Suppose you would like to see all the commits reachable from the branch head named master but not from any other head in your repository. And then we can ask to see all the commits reachable from master but not from these other heads:. Creating a changelog and tarball for a software release The git-archive[1] command can create a tar or zip archive from any version of a project; for example:. Linus Torvalds, for example, makes new kernel releases by tagging them, then running:.
Finding commits referencing a file with given content Somebody hands you a copy of a file, and asks which commits modified a file such that it contained the given content either before or after the commit. Developing with Git Telling Git your name Before creating any commits, you should introduce yourself to Git.
Which will add the following to a file named. Creating a new repository Creating a new repository from scratch is very easy:. How to make a commit Creating a new commit takes three steps:. Making some changes to the working directory using your favorite editor. Telling Git about your changes. Creating the commit using the content you told Git about in step 2. Ignoring files A project will often generate files that you do not want to track with Git. Lines starting with ' ' are considered comments.
Ignore any file named foo. How to merge You can rejoin two diverging branches of development using git-merge[1] :. All you need to do is edit the files to resolve the conflicts, and then.
Getting conflict-resolution help during a merge All of the changes that Git was able to merge automatically are already added to the index file, so git-diff[1] shows only the conflicts. Some special diff options allow diffing the working directory against any of these stages:. Undoing a merge If you get stuck and decide to just give up and throw the whole mess away, you can always return to the pre-merge state with.
Fast-forward merges There is one special case not mentioned above, which is treated differently. Fixing a mistake with a new commit Creating a new commit that reverts an earlier change is very easy; just pass the git-revert[1] command a reference to the bad commit; for example, to revert the most recent commit:.
You can also revert an earlier change, for example, the next-to-last:. Fixing a mistake by rewriting history If the problematic commit is the most recent commit, and you have not yet made that commit public, then you may just destroy it using git reset. Checking out an old version of a file In the process of undoing a previous bad change, you may find it useful to check out an older version of a particular file using git-restore[1].
Temporarily setting aside work in progress While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. After that, you can go back to what you were working on with git stash pop :.
Ensuring good performance On large repositories, Git depends on compression to keep the history information from taking up too much space on disk or in memory. Ensuring reliability Checking the repository for corruption The git-fsck[1] command runs a number of self-consistency checks on the repository, and reports on any problems.
Recovering lost changes Reflogs Say you modify a branch with git reset --hard , and then realize that the branch was the only reference you had to that point in history.
Examining dangling objects In some situations the reflog may not be able to save you. Sharing development with others Getting updates with git pull After you clone a repository and commit a few changes of your own, you may wish to check the original repository for updates and merge them into your own work.
Submitting patches to a project If you just have a few changes, the simplest way to submit them may just be to send them as patches in email:. Looks like I have to use the one on the net. Grant Zvolsky Grant Zvolsky 1 1 silver badge 4 4 bronze badges. I don't think that's what OP is asking. That's what OP is looking for. That's for a specific command, I know that. Then it can be read using less , or perhaps a combination of cat and grep Example: read the first lines of chapter 'Exploring Git history' cat user-manual.
Mehdi Mehdi 6, 1 1 gold badge 31 31 silver badges 40 40 bronze badges. Martian Martian 8 8 bronze badges. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. Podcast Making Agile work for data science. Stack Gives Back Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually.
Related Hot Network Questions. Question feed. Stack Overflow works best with JavaScript enabled.
0コメント