You already know that the "git log" command provides you with an overview of recent commits. If you want to see only changes that have already been added to the Staging Area, "git diff -staged" is your command of choice. Without further options, "git diff" will show us all current local changes in our working copy that are unstaged. To understand how they were changed in detail, we can ask "git diff": $ git diff You can not only see which lines were changed in a file, but - thanks to the inline highlighting feature - what exactly was changed:Įarlier in the book, we often used the "git status" command to see which files were currently changed in our working copy. In case you are using the Tower Git client, its integrated Diff Viewer helps you understand changes quickly. Now that we know how to read a diff output, let's generate some! In change #3, finally, some lines were actually modified: the two "-" lines were changed to look like the two "+" lines below.However, B doesn't have an equivalent (no "+" lines), meaning they were deleted. Change #2 is just the opposite: in A, we have two lines marked with "-" signs.Since no counterpart in A existed for these lines (no lines with "-"), this means that these lines were added. Change #1 contains two lines prepended with a "+".In most cases, Git picks A and B in such a way that you can think of A/- as "old" content and B/+ as "new" content. As explained, these symbols help you understand how exactly version A and B look: a line that is prepended with a "-" sign comes from A, while a line with a "+" sign comes from B. ChangesĮach changed line is prepended with either a "+" or a "-" symbol. However, this greatly depends on the programming language and doesn't work in all scenarios. The text after the closing pair of aims to clarify the context, again: Git tries to display a method name or other contextual information of where this chunk was taken from in the file. From file B (represented by a "+"), 8 lines are displayed, also starting from line no.From file A (represented by a "-"), 6 lines are extracted, beginning from line no.In our case the following lines are represented in the first chunk: Enclosed in two signs each, Git tells you which lines were affected. Chunk HeaderĮach of these chunks is prepended by a header. In addition to the actual changed lines, a chunk also contains a bit of "context": some (unchanged) lines before and after the modification so you can better understand in what context that change happened. Such a portion is called a "chunk" (or "hunk"). Instead, it only shows those portions that were actually modified. ChunkĪ diff doesn't show the complete file from beginning to end: you wouldn't want to see everything in a 10,000 lines file, when only 2 lines have changed. In order to tell them apart, A and B are each assigned a symbol: for version A, this is a minus ("-") sign and for version B, a plus ("+") sign is used. Markers for a/bįurther down in the output, the actual changes will be marked as coming from A or B. The last number is an internal file mode identifier (100644 is just a "normal file", while 100755 specifies an executable file and 120000 represents a symbolic link). Such a hash identifies a file object at a specific revision. The first two numbers represent the hashes (or, simply put: "IDs") of our two files: Git saves every version not only of the project but also of each file as an object. The file metadata shown here is a very technical information which you'll probably never need in practice. To make clear what is actually compared, a diff output always starts by declaring which files are represented by "A" and "B". Although not used very often, a diff could also compare two completely unrelated files with each other to show how they differ. In most cases, A and B will be the same file, but in different versions. Our diff compares two items with each other: item A and item B. Let's take a detailed look at such a diff - and learn how to read it. In version control, differences between two versions are presented in what's called a "diff" (or, synonymously, a "patch").
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |