What do you think?
Rate this book
Pro Git
Git is the version control system developed by Linus Torvalds for Linux kernel development. It took the open source world by storm since its inception in 2005, and is used by small development shops and giants like Google, Red Hat, and IBM, and of course many open source projects.
A book by Git experts to turn you into a Git expert. Introduces the world of distributed version control Shows how to build a Git development workflow.
A book by Git experts to turn you into a Git expert. Introduces the world of distributed version control Shows how to build a Git development workflow.
290 pages, Paperback
First published January 1, 2009
3536 people are currently reading
3974 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 304 reviews
October 2, 2015
Despite what the title would indicate, this is targeted at beginners. It teaches you git assuming you have passing knowledge about VCSs — and does a pretty great job teaching the basics — but leaves a lot of open questions about intermediate topics, like branching strategies (and each of their benefits and drawbacks).
Update: I've bumped this from two to three stars since the book does have some good value. I've told many beginners to read the first several chapters to get a good foundation. Intermediate and advanced users will want to turn to the reference, the web, or their local expert.
Git is great, but with this book you’ll have to tolerate a fanatic and contemptible tone and spurious comparisons to existing VCSs, and you'll also be fed some misinformation. For example, In "Snapshots, Not Differences" he says that Subversion (among other VCSs) only stores revision changes as diffs to files rather than as a snapshot of the what the file system looks like at every revision. While this does correctly describe CVS, it is incorrect about Subversion, in which each revision points to a complete snapshot of the file system (in a clever and efficient manner).
This is in addition to that he's comparing one aspect of other VCSs (how file differences are stored) to a different aspect of Git (how the tree is stored). While doing so, he implies that Git does not use diffs when a file changes (for better performance at the cost of space). Not entirely true; Git may use packfile as it sees fit. Similarly, SVN uses reverse diffs and skip-deltas for best performance while making efficient use of space.
Update: I've bumped this from two to three stars since the book does have some good value. I've told many beginners to read the first several chapters to get a good foundation. Intermediate and advanced users will want to turn to the reference, the web, or their local expert.
Git is great, but with this book you’ll have to tolerate a fanatic and contemptible tone and spurious comparisons to existing VCSs, and you'll also be fed some misinformation. For example, In "Snapshots, Not Differences" he says that Subversion (among other VCSs) only stores revision changes as diffs to files rather than as a snapshot of the what the file system looks like at every revision. While this does correctly describe CVS, it is incorrect about Subversion, in which each revision points to a complete snapshot of the file system (in a clever and efficient manner).
This is in addition to that he's comparing one aspect of other VCSs (how file differences are stored) to a different aspect of Git (how the tree is stored). While doing so, he implies that Git does not use diffs when a file changes (for better performance at the cost of space). Not entirely true; Git may use packfile as it sees fit. Similarly, SVN uses reverse diffs and skip-deltas for best performance while making efficient use of space.
August 19, 2014
Every programmer should have read at leas on git book and this one is a good candidate.
Even if I've already did my part, I enjoy reading a git book every now and then. I usually find out a few things that I did not know or I "cement" existing knowledge. I learned a couple of new tricks.
The first few chapters explain the basics that you're probably familiar with. They do it in a very nice way (lot's of pictures and examples) and I could understand most of it without having to start my computer and try things out.
The last few chapters (6. Git tools, 7. Customizing Git and especially 9. Git Internals) are awesome even if you're already quite experiences. I learned a bunch of very interesting things:
- Using Subtree merging instead of submodules to vendor another code base
- Cool things you can do with git attributes (like diffing word documents and images or processing files after checkout and before staging).
- How to construct a git commit with just the plumbing commands
It's also available online for free :)
Even if I've already did my part, I enjoy reading a git book every now and then. I usually find out a few things that I did not know or I "cement" existing knowledge. I learned a couple of new tricks.
The first few chapters explain the basics that you're probably familiar with. They do it in a very nice way (lot's of pictures and examples) and I could understand most of it without having to start my computer and try things out.
The last few chapters (6. Git tools, 7. Customizing Git and especially 9. Git Internals) are awesome even if you're already quite experiences. I learned a bunch of very interesting things:
- Using Subtree merging instead of submodules to vendor another code base
- Cool things you can do with git attributes (like diffing word documents and images or processing files after checkout and before staging).
- How to construct a git commit with just the plumbing commands
It's also available online for free :)
August 3, 2016
Cool read. 2 hours of reading / first 100 pages were just enough to make my everyday life with git an exciting experience. Some do uncover lots of internals - feel free to skim.
--
Some of my takeaways:
1. Every revision in git is a snapshot
2. Every revision has a parent(or multiple ones in case of merge)
3. Rebasing won't nuke your old revisions - that's just like basing whole new revision chain with the changes you made
4. Branches are just references to revisions - thus you can point this reference to point to a rebase result modifying the whole branch history
5. Changes you make are [not staged] -> [staged] -> [committed] -> [published/pushed]
6. Rebase yields clearer histories than merging but rebasing history someone based some work on is not the thing you'd like to do :)
7. Forking project on github just copies the hole repository over
8. origin is a remote reference to the repository you did a clone from
9. upstream is usually a reference to the repository you did a fork from
10. git is awesome <3
--
Some of my takeaways:
1. Every revision in git is a snapshot
2. Every revision has a parent(or multiple ones in case of merge)
3. Rebasing won't nuke your old revisions - that's just like basing whole new revision chain with the changes you made
4. Branches are just references to revisions - thus you can point this reference to point to a rebase result modifying the whole branch history
5. Changes you make are [not staged] -> [staged] -> [committed] -> [published/pushed]
6. Rebase yields clearer histories than merging but rebasing history someone based some work on is not the thing you'd like to do :)
7. Forking project on github just copies the hole repository over
8. origin is a remote reference to the repository you did a clone from
9. upstream is usually a reference to the repository you did a fork from
10. git is awesome <3
April 24, 2021
Great reference book with a lot of chapters that will help you with your day-to-day interactions with git.
I am more confident about using git then I was before reading this book. The Git internals chapter is really cool especially the Data recovery section, also all of the information related to rewriting history is a gem as well.
Even though I've tried to read the book cover to cover I wouldn't try that approach again because there is just so much information that I can't possibly remember. I've skimmed some of the chapters like Github and Git on the server. I've skipped entirely Git and Other Systems chapter. Though it's good to know that if I work on a project that doesn't use git, I can still use it locally or even migrate the project to git if that is possible.
If you are new to git I would recommend first reading this great intro.
I am more confident about using git then I was before reading this book. The Git internals chapter is really cool especially the Data recovery section, also all of the information related to rewriting history is a gem as well.
Even though I've tried to read the book cover to cover I wouldn't try that approach again because there is just so much information that I can't possibly remember. I've skimmed some of the chapters like Github and Git on the server. I've skipped entirely Git and Other Systems chapter. Though it's good to know that if I work on a project that doesn't use git, I can still use it locally or even migrate the project to git if that is possible.
If you are new to git I would recommend first reading this great intro.
October 24, 2013
Awesome. Absolutely brilliant.
It's the best introduction to Git you can imagine.
Full of real-life examples and typical scenarios, not afraid of describing the internals - but not to overcomplicate things. Everything has its purpose in this book and as a result it's the greatest tutorial to Git one can imagine.
Personally, I already knew and used Git earlier, but until now, I didn't understand its functionality as good as I should -> this book is a true eye-opener. HIGHLY recommended.
P.S. On the top of all that - it's for free. Can one wish for more?
It's the best introduction to Git you can imagine.
Full of real-life examples and typical scenarios, not afraid of describing the internals - but not to overcomplicate things. Everything has its purpose in this book and as a result it's the greatest tutorial to Git one can imagine.
Personally, I already knew and used Git earlier, but until now, I didn't understand its functionality as good as I should -> this book is a true eye-opener. HIGHLY recommended.
P.S. On the top of all that - it's for free. Can one wish for more?
December 24, 2017
This is a good book. It's definitely what I wanted to read about Git. No useless chapters, no over complicated examples. Nuff said, Git is the best. Just read it.
June 2, 2022
It's unfortunate that I didn't get a chance to read this sooner. It gives you a very deep understanding of how git works and how it is designed underneath.
February 23, 2014
I have been using both Subversion and Git over the past 7 years or so. I prefer Git but do not dismiss Subversion as irrelevant.
This is a very good introduction to Git. Yes, it is still an introduction. I've read and compiled a lot more Git tips and commands that only someone who works in a distributed team would use.
If you read this, you should also read about defensive programming and why you have to fail early and OPENLY! At first, I thought that is just insane. But there's no other sensible way of working.
Some workflows have been shown in the book but without much detail. You might want to check out Git Flow.
This is a very good introduction to Git. Yes, it is still an introduction. I've read and compiled a lot more Git tips and commands that only someone who works in a distributed team would use.
If you read this, you should also read about defensive programming and why you have to fail early and OPENLY! At first, I thought that is just insane. But there's no other sensible way of working.
Some workflows have been shown in the book but without much detail. You might want to check out Git Flow.
September 26, 2021
This book is highly regarded among GitHub employees (source: I have been one since 2017), and for no small reason. Even if you are comfortable with your current Git knowledge, Chapter 10 (Git Internals) introduces the "plumbing" (low-level) vs "porcelain" (high-level) divide and has a fun exercise of "reconstructing" the high-level git entities (files, commits, branches, etc.) from the "bottom up" - it is unlikely you'll ever do anything like that on typical git usage, but understanding those concepts is (IMHO) akin to understanding Assembly/C when programing in higher-level languages.
November 19, 2014
Some parts of the book were eye-opening for me. It's building a pyramid of knowledge, but it doesn't look like that until you reach the final chapter - Internals. Only after reading it I managed to connect all the dots.
Read
August 7, 2025If there really is any sufficiently advanced technology indistinguishable from magic, it has to be Git. Millions of developers (source: voices in my head) blindly cast spells they memorized from Stack Overflow, without the slightest understanding of what the hell is actually happening. Ask any of them whether Git stores snapshots or deltas and you’ll get the same vague handwaving and confused mumbling you’d get if you asked a cryptobro how blockchain actually works.
It’s not really the users’ fault, though. There’s a quote from Pro Git that sheds some light:
And I think the opposite perspective is just as valid: complex systems evolve over time. It’s hard to plan things perfectly on the first try. Even if you think you’ve come up with a convenient UX, your users will absolutely find a way to use it completely differently. They’ll find shortcuts and hacks and eventually create their own cargo cult around it.
So does this book help unravel the mysteries of Git? To a certain extent, yes. The first three chapters walk you through the basics. It might even cover a few blind spots you’ve been carrying around (you secretly hope nobody ever notices), but never bother to fix by reading the docs. What happens after that?
Well, you spend the rest of the book learning how to apply Git in situations you hope you never get into. What if someone pushes changes to a branch you share with someone (why?), and in the meantime, you need to merge the hotfix and master branches — both from different remotes? Or any other mental illness people suffer from instead of using a straightforward Git workflow. What if you want to find a Git object, but someone did rm -rf .git/logs? What if you want to store Git on a tape drive? What if you want to use Git as a client with an SVN repository? How do you trick Git into thinking you’ve already merged changes without actually merging them?
My main complaint while reading the book was that yes, Git is an extremely powerful system, a “content-addressable filesystem” even. But half the examples made me feel like the book is just trying to justify all the weird levers and switches Git has, just for the sake of “WHAT IF?” I don’t know, what if an asteroid crashes into Earth. Does Git have an option to fix that?
Which leads me to my next complaint — the structure. I didn’t check the first edition, but as far as I know, it was twice as short. The whole structure of the book feels… weird. Like, why is there a chapter on “Git on the Server” — a pretty niche topic these days — before “Distributed Git,” where you describe how to actually collaborate with Git? I bet there are more Git users than Git administrators. Why is there a whole “GitHub” chapter? Is that really necessary — and more important than Git tools like git blame and friends? “Git and Other Systems” describes how to use Git with ancient VCS tools… really?
You do learn something new, but at the same time, it feels like bells and whistles — like the people who wrote Git wanted to solve more problems than they needed to, and in the pursuit of scope, they lost track of the things right in front of them.
P.S. I still respect Scott Chacon as an educator. Watch his other videos if you want to know more about Git:
* https://www.youtube.com/watch?v=aolI_...
* https://www.youtube.com/watch?v=Md44r...
It’s not really the users’ fault, though. There’s a quote from Pro Git that sheds some light:
But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts.
And I think the opposite perspective is just as valid: complex systems evolve over time. It’s hard to plan things perfectly on the first try. Even if you think you’ve come up with a convenient UX, your users will absolutely find a way to use it completely differently. They’ll find shortcuts and hacks and eventually create their own cargo cult around it.
So does this book help unravel the mysteries of Git? To a certain extent, yes. The first three chapters walk you through the basics. It might even cover a few blind spots you’ve been carrying around (you secretly hope nobody ever notices), but never bother to fix by reading the docs. What happens after that?
Well, you spend the rest of the book learning how to apply Git in situations you hope you never get into. What if someone pushes changes to a branch you share with someone (why?), and in the meantime, you need to merge the hotfix and master branches — both from different remotes? Or any other mental illness people suffer from instead of using a straightforward Git workflow. What if you want to find a Git object, but someone did rm -rf .git/logs? What if you want to store Git on a tape drive? What if you want to use Git as a client with an SVN repository? How do you trick Git into thinking you’ve already merged changes without actually merging them?
My main complaint while reading the book was that yes, Git is an extremely powerful system, a “content-addressable filesystem” even. But half the examples made me feel like the book is just trying to justify all the weird levers and switches Git has, just for the sake of “WHAT IF?” I don’t know, what if an asteroid crashes into Earth. Does Git have an option to fix that?
Which leads me to my next complaint — the structure. I didn’t check the first edition, but as far as I know, it was twice as short. The whole structure of the book feels… weird. Like, why is there a chapter on “Git on the Server” — a pretty niche topic these days — before “Distributed Git,” where you describe how to actually collaborate with Git? I bet there are more Git users than Git administrators. Why is there a whole “GitHub” chapter? Is that really necessary — and more important than Git tools like git blame and friends? “Git and Other Systems” describes how to use Git with ancient VCS tools… really?
You do learn something new, but at the same time, it feels like bells and whistles — like the people who wrote Git wanted to solve more problems than they needed to, and in the pursuit of scope, they lost track of the things right in front of them.
P.S. I still respect Scott Chacon as an educator. Watch his other videos if you want to know more about Git:
* https://www.youtube.com/watch?v=aolI_...
* https://www.youtube.com/watch?v=Md44r...
October 25, 2020
Some repos are down, some command lines are outdated but still one of the classic
Would definitely recommend
Would definitely recommend
February 10, 2019
Before I begin, an introduction is in order, to provide a little context. I'm a Windows .NET developer, and have been using Git for the past eight years or so. I use it in both my day job (the projects we work on are all source controlled in Git these days), but also in my writing business, to source control the Scrivener projects for my books. It's a fantastic tool for version controlling any kind of file you can think of.
Although I am comfortable with various graphical wrappers, I've also always prefered the Git Bash interface, perhaps because I've always liked Bash's simplicity and elegance, having played around with various flavours of Linux over the years.
With that out of the way, what did I think of this book?
I thought I was pretty knowledgable about Git before. I was wrong.
This book is a fantastic reference, and it showed me that the things I was using Git for barely constitute 10% of everything it's capable of. It's not like I've been doing this wrong necessarily; it's just that there are so many better ways to achieve many of the things I've been trying to do. For example, I knew about rebasing, but I've always been a bit afraid of it. I'm going to be using it more from now on (although as the book points out, I'm going to avoid rebasing anything I've already pushed up).
I also can't tell you how many times I've made a commit, forgot to add a file, and then had to make a second commit immediately afterwards. I'll be using git commit --amend more often now.
Finally, I can't wait for an excuse to use git bisect to find the exact commit where something stopped working!
Another thing I never really understood is why you would use fetch and not pull. Although I now understand the difference much more clearly, I'm still going to keep using pull (perhaps with --rebase, though), since I don't remember ever being in a situation where I had more than one remote for my repository.
This book is staying on my e-reader, and I'll be referring back to it constantly.
On the downside, the formatting of the Kindle Edition isn't great. I like to read white text on a black background because of my visual disability--I need the contrast--but for some reason, clickable URLs in this book (and there are many) are coloured in dark orange. Also, the code samples are a bit difficult to follow at times, because they're indented and don't flow very well on the large font size I tend to use.
Speaking of code samples, all git commands embedded in the narrative are formatted in fixed-pitch font (which is a good thing), but that formatting is inconsistent, so you sometimes see things which you think are supposed to be part of the command, but they're actually part of the narrative, or vice versa.
And the index at the end isn't linked, which makes it completely useless since there's no way to click on a term to go directly to that chapter.
Other than that, it's an entertaining and informative read. I nodded and smiled a few times, as the authors describe some pain I've already been through, but I stared at the screen and went "Wow! I never knew that." many more times that that.
Although I am comfortable with various graphical wrappers, I've also always prefered the Git Bash interface, perhaps because I've always liked Bash's simplicity and elegance, having played around with various flavours of Linux over the years.
With that out of the way, what did I think of this book?
I thought I was pretty knowledgable about Git before. I was wrong.
This book is a fantastic reference, and it showed me that the things I was using Git for barely constitute 10% of everything it's capable of. It's not like I've been doing this wrong necessarily; it's just that there are so many better ways to achieve many of the things I've been trying to do. For example, I knew about rebasing, but I've always been a bit afraid of it. I'm going to be using it more from now on (although as the book points out, I'm going to avoid rebasing anything I've already pushed up).
I also can't tell you how many times I've made a commit, forgot to add a file, and then had to make a second commit immediately afterwards. I'll be using git commit --amend more often now.
Finally, I can't wait for an excuse to use git bisect to find the exact commit where something stopped working!
Another thing I never really understood is why you would use fetch and not pull. Although I now understand the difference much more clearly, I'm still going to keep using pull (perhaps with --rebase, though), since I don't remember ever being in a situation where I had more than one remote for my repository.
This book is staying on my e-reader, and I'll be referring back to it constantly.
On the downside, the formatting of the Kindle Edition isn't great. I like to read white text on a black background because of my visual disability--I need the contrast--but for some reason, clickable URLs in this book (and there are many) are coloured in dark orange. Also, the code samples are a bit difficult to follow at times, because they're indented and don't flow very well on the large font size I tend to use.
Speaking of code samples, all git commands embedded in the narrative are formatted in fixed-pitch font (which is a good thing), but that formatting is inconsistent, so you sometimes see things which you think are supposed to be part of the command, but they're actually part of the narrative, or vice versa.
And the index at the end isn't linked, which makes it completely useless since there's no way to click on a term to go directly to that chapter.
Other than that, it's an entertaining and informative read. I nodded and smiled a few times, as the authors describe some pain I've already been through, but I stared at the screen and went "Wow! I never knew that." many more times that that.
December 29, 2017
Chapters review/summary:
1) Some history and installation options. Differences between centralised VCS and distributed, what makes git different from other distributed: features like branching and working with large codebases in the way that branches are just pointers to a commit and each commit has snapshots of the tracked files at a point in time rather than tracking the delta between file revisions, three main states: committed, stated and modified; which is the same as: git directory, staging area (or index) and working tree/directory.
2) The basics, commands like: add, commit, push, log, status, tag. Configure gitignore, what are remotes and how to use them, how to tag, create aliases, do things like "git mv myFile myFileRename" so git knows about a rename in one single command rather than multiple steps (same for "rm"), how to unstage
3) Branching explained, branching management and strategies, merging and rebasing. Don't rebase work you've pushed to remote as it may cause problems to others tracking the same branch on the remote, try to rebase only local commits.
1) Some history and installation options. Differences between centralised VCS and distributed, what makes git different from other distributed: features like branching and working with large codebases in the way that branches are just pointers to a commit and each commit has snapshots of the tracked files at a point in time rather than tracking the delta between file revisions, three main states: committed, stated and modified; which is the same as: git directory, staging area (or index) and working tree/directory.
2) The basics, commands like: add, commit, push, log, status, tag. Configure gitignore, what are remotes and how to use them, how to tag, create aliases, do things like "git mv myFile myFileRename" so git knows about a rename in one single command rather than multiple steps (same for "rm"), how to unstage
3) Branching explained, branching management and strategies, merging and rebasing. Don't rebase work you've pushed to remote as it may cause problems to others tracking the same branch on the remote, try to rebase only local commits.
September 18, 2013
Este libro es uno de los mejores libros técnicos que he leído últimamente. Cubre todo lo que necesitas saber desde el uso más básico al más avanzado, con muchos esquemas y ejemplos. El tipo que lo ha escrito es el que está detrás de http://git-scm.com/. Se puede leer gratis en PDF pero a mí este tipo de libros me gusta leerlos en papel. Me encanta Git y aunque ya llevaba algún tiempo usándolo antes de empezar Pro Git, leerlo me ha ayudado a entender bastantes cosas con muchísima más profundidad y claridad.
El mejor capítulo en mi opinión es el último, en el que se explican los Git internals: cómo funciona Git por dentro, los plumbing commands para hacer cosas de bajo nivel... Te ayuda muchísimo a entender lo que realmente está pasando con tu repositorio. Es un capítulo que no es necesario ni mucho menos para el uso normal de Git, pero que si lo lees te aporta un gran poder :)
El mejor capítulo en mi opinión es el último, en el que se explican los Git internals: cómo funciona Git por dentro, los plumbing commands para hacer cosas de bajo nivel... Te ayuda muchísimo a entender lo que realmente está pasando con tu repositorio. Es un capítulo que no es necesario ni mucho menos para el uso normal de Git, pero que si lo lees te aporta un gran poder :)
September 18, 2012
This book provides a good introduction to using Git. As with most educational books, the examples presented are more helpful if the reader works through them while reading the text. Because the book is freely available online as well as available in print it is in my opinion a must-read for Git newcomers.
Some reviewers complain that the book spends too much time comparing Git to other source code management (SCM) software, but I would argue that this characteristic is beneficial to readers relatively new to SCMs. The comparisons throughout will give inexperienced readers knowledge of the language surrounding SCM software and enable them to talk about Git with users of other SCMs without having to also be experienced with those other SCMs. That said, the book could just as easily have been titled "Pro-Git."
Some reviewers complain that the book spends too much time comparing Git to other source code management (SCM) software, but I would argue that this characteristic is beneficial to readers relatively new to SCMs. The comparisons throughout will give inexperienced readers knowledge of the language surrounding SCM software and enable them to talk about Git with users of other SCMs without having to also be experienced with those other SCMs. That said, the book could just as easily have been titled "Pro-Git."
June 11, 2017
I had to learn git in a meaningful way, not just the cursory way I did. I love good technical books, and this is one. Git isn't rocket science, but does require an understanding of the conceptual model to work with it..it's easy to go down a rabbit hole otherwise.
This is basically a must-read for digital designers and UX Designers. Not knowing this will make collaboration with product engineers difficult. I read a lot of this on a Sunday afternoon, and that was casual reading. It's also available for free online...read it, learn it, and elevate your practice.
This is basically a must-read for digital designers and UX Designers. Not knowing this will make collaboration with product engineers difficult. I read a lot of this on a Sunday afternoon, and that was casual reading. It's also available for free online...read it, learn it, and elevate your practice.
November 22, 2016
The second edition of Pro Git, definitely worth reading. Available for free at https://git-scm.com/book/en/v2.
Git can be confusing and unnecessarily complex for beginners. In this book, you get extensive explanation. I will have to re-read some parts.
Git can be confusing and unnecessarily complex for beginners. In this book, you get extensive explanation. I will have to re-read some parts.
May 4, 2021
This is one of the most essential books/tools for programmers.
Context was great, easy to learn, eased by graphical patterns and samples, you have no excuse to not master it.
Context was great, easy to learn, eased by graphical patterns and samples, you have no excuse to not master it.
March 16, 2019
Mi-a plăcut foarte mult „Pro Git”. Cred că Scott Chacon a acoperit absolut toate necesitățile pe care le-ai putea avea vis-a-vis de Git, explicând într-un mod foarte clar și simplu. Am învățat despre comenzile ”porcelain” și ”plumbing”, am descoperit bloburile, tree-urile, obiectele de tip commit și modul cum funcționează intern Git, am citit cu interes despre cum poți recupera commituri pierdute, despre cum poți migra dintr-un alt VCS , ba chiar despre cum poți folosi Git ca și client al altor VCSs importante.
Trebuie să recunosc că a fost pentru prima dată când am folosit Git Bash pentru toate comenzile ”de porțelan”, pe care în mod normal le execut folosind GUIs precum Source Tree, Fork sau Git Tortoise. Și nu a fost deloc dificil. Dimpotrivă, am ajuns să apreciez simplitatea și forța executării comenzilor în Bash.
De asemenea, mi s-a părut genial faptul că a sfârșit în Apendice cu o recapitulare a tuturor comenzilor și a locului din carte unde a vorbit despre ele. Această abordare e utilă și din punct de vedere pedagogic, pentru că ajută la înrădăcinarea cunoștințelor tocmai acumulate.
Nu pot încheia decât cu entuziasm. Am savurat cartea și am citit cu mult interes despre multitudinea aspectelor lumii Git.
Trebuie să recunosc că a fost pentru prima dată când am folosit Git Bash pentru toate comenzile ”de porțelan”, pe care în mod normal le execut folosind GUIs precum Source Tree, Fork sau Git Tortoise. Și nu a fost deloc dificil. Dimpotrivă, am ajuns să apreciez simplitatea și forța executării comenzilor în Bash.
De asemenea, mi s-a părut genial faptul că a sfârșit în Apendice cu o recapitulare a tuturor comenzilor și a locului din carte unde a vorbit despre ele. Această abordare e utilă și din punct de vedere pedagogic, pentru că ajută la înrădăcinarea cunoștințelor tocmai acumulate.
Nu pot încheia decât cu entuziasm. Am savurat cartea și am citit cu mult interes despre multitudinea aspectelor lumii Git.
May 19, 2021
This book coupled with MIT's Missing Semester lecture video on version control were what I needed to finally feel comfortable using git (as opposed to treating git commands as arcane incantations). Great resource and reference. I read 6 of the 10 chapters; the rest of the book goes into more depth than I currently care for. The most important ideas for someone new to git are covered in the first 3 chapters. For a technical book, it reads easily.
February 27, 2024
Beautiful book. This should be pretty much a mandatory reading for all programmers.
And could be very helpfull for non programers working with text, or stuff that changes a lot.
After using git as a casually user for 10 years, I finally understood what was I actually doing all that time.
And could be very helpfull for non programers working with text, or stuff that changes a lot.
After using git as a casually user for 10 years, I finally understood what was I actually doing all that time.
August 27, 2021
great book , I believe this book is best used as a desktop reference .
February 17, 2022
This was the best book on Git that I have read.
It was so comprehensive.
Definitely an excellent guide to have on hand when coding.
Would recommend for anyone who programs.
4.8/5
It was so comprehensive.
Definitely an excellent guide to have on hand when coding.
Would recommend for anyone who programs.
4.8/5
May 23, 2024
It teaches you all you really need to know about git in a concise way, I desire nothing more from this book
January 22, 2018
lots of details to get a solid grasp on Git.
January 25, 2019
You’re about to spend several hours of your life reading about Git.
I sure did! Honestly, the only think I didn't like about this was the title, because it's misleading: this is not for pros, but a manual for people that are just getting started on git like me, and it's so useful! I especially liked that it explaing how and why some things work in git, instead of just giving you the commands to run. I loved the step-by-step guide to both gitlabs and github! Just what I needed. It definetly helped me and I bet it will help me more in the future when I get lost. A to read to everyone getting started on git!
February 6, 2025
A good free resource to get an introduction to Git.
August 8, 2009
A reasonably clear introduction and explanation of git. The first part does a good job at explaining things for new users, and is especially good at pointing out saner ways to do things that were added in recent versions of git. It seemed to cover most of the stuff I've learned the hard way, and I found one or two new things. The only glaring omission is it didn't seem to cover git reset at all.
The chapter on managing a project with git covered problems I'm just starting to encounter, so was appreciated. The section on subprojects showed all their many warts; candor appreciated. The coverage of subtree merging was entirely new to me and very interesting to see. The final chapter on internals does a good job of really getting down and dirty at both the git database and wire protocol levels.
The only things I didn't like were some slightly shady bits of sysadmin advice. In at least two places the user is advised to set up things in an insecure way. (I hope to get these corrected.) In other places the user is walked through cloning a project from git and manually installing it -- even though apt-get is used to install other things on sometimes the same page.
The chapter on managing a project with git covered problems I'm just starting to encounter, so was appreciated. The section on subprojects showed all their many warts; candor appreciated. The coverage of subtree merging was entirely new to me and very interesting to see. The final chapter on internals does a good job of really getting down and dirty at both the git database and wire protocol levels.
The only things I didn't like were some slightly shady bits of sysadmin advice. In at least two places the user is advised to set up things in an insecure way. (I hope to get these corrected.) In other places the user is walked through cloning a project from git and manually installing it -- even though apt-get is used to install other things on sometimes the same page.
November 16, 2022
I was working with git for some time and read already a lot of different articles about it. I decided that lets read and learn something new. And unfortunately this book doesn't introduce into git in the good way. Examples are difficult to understand and even with my knowledge I was wondering what they mean. Book also describes use cases which can be used couple times in the life (like importing repository from svn) and probably if somebody hit this use-case he will open internet. Book is written couple years ago and right now it is not up to date. For example one chapter describes GitHub with the pictures. Of course from the moment when the book was written on the GitHub everything had changed. I don't recommend especially for the newbies as for them book will show that git is difficult and magic, which is not true.
Displaying 1 - 30 of 304 reviews