What do you think?
Rate this book
GIT: Dezentrale Versionsverwaltung im Team - Grundlagen und Workflows
Git ist ein mächtiges Werkzeug zur verteilten Versionsverwaltung. Es macht vieles möglich, was mit klassischen Versionsverwaltungen gar nicht oder nur unter großen Mühen ging. Gits Vielfalt an Kommandos, Optionen und Konfigurationen wirkt anfangs oft einschüchternd - obwohl die Grundkonzepte einfach sind und man meist nur wenige Befehle benötigt.
Die Autoren dieses Buches bieten daher zunächst eine kompakte Einführung in die Konzepte und jene Befehle, die man im Entwickleralltag wirklich benötigt. Anschließend widmen sie sich ausführlich den wichtigsten Workflows bei der Softwareentwicklung im Team und zeigen, wie Git dort eingesetzt wird. Behandelt werden u.a. die folgenden Workflows:
- Ein Projekt aufsetzen
- Mit Feature-Branches entwickeln
- Gemeinsam auf einem Branch arbeiten
- Ein Release durchführen
- Mit Bisection Fehler finden
- Große Projekte aufteilen
Das Buch richtet sich an professionelle Softwareentwickler, die bereits Erfahrung mit klassichen Versionsverwaltungssystemen wie CVS, Subversion oder ClearCase verfügen.
Sie lernen in diesem Buch alle wichtigen Git-Befehle und -Funktionen kennen und erfahren, wie Sie sie effektiv anwenden. Zudem entdecken Sie neue Einsatzgebiete von dezentralen Versionsverwaltungen, die in klassischen, zentralen Systemen nicht existieren.
Die Autoren dieses Buches bieten daher zunächst eine kompakte Einführung in die Konzepte und jene Befehle, die man im Entwickleralltag wirklich benötigt. Anschließend widmen sie sich ausführlich den wichtigsten Workflows bei der Softwareentwicklung im Team und zeigen, wie Git dort eingesetzt wird. Behandelt werden u.a. die folgenden Workflows:
- Ein Projekt aufsetzen
- Mit Feature-Branches entwickeln
- Gemeinsam auf einem Branch arbeiten
- Ein Release durchführen
- Mit Bisection Fehler finden
- Große Projekte aufteilen
Das Buch richtet sich an professionelle Softwareentwickler, die bereits Erfahrung mit klassichen Versionsverwaltungssystemen wie CVS, Subversion oder ClearCase verfügen.
Sie lernen in diesem Buch alle wichtigen Git-Befehle und -Funktionen kennen und erfahren, wie Sie sie effektiv anwenden. Zudem entdecken Sie neue Einsatzgebiete von dezentralen Versionsverwaltungen, die in klassischen, zentralen Systemen nicht existieren.
- GenresProgrammingSoftware
275 pages, Paperback
First published June 1, 2012
4 people are currently reading
19 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 - 4 of 4 reviews
August 28, 2022
In its last chapter, "The Limits of Git", Git: Dezentrale Versionsverwaltung im Team points to the complexity and long familiarization time. To me this was a surprising fact and what actually brought me to pick up a whole book on the topic. If you are like me, you may have expected it to be enough to quickly go over some overview articles online and you would be up to speed. I'm sure there are some great articles, but for many this will soon lead to a frustrating experience of opaque error messages and warnings and an increasing insecurity on whether you are using the system as intended.
Until reading this book, there was very little structure to my use of the version control system. I looked up commands online, tried to ignore details (like the upstream option), and hoped that pushes and pulls would get through (don't get me started on branches!). If not I somehow managed to get around by trial and error (and by following the suggestions on Git's excellent command-line advice). Alien concepts, like "origin" or "main", I tried to ignore. Not exactly a great user experience, and certainly nothing you could get away with in a more professional setting.
The first two or three chapters (depending on whether you are interested in the GUI approach) give a concise overview of the core concepts before explaining them in individual chapters (4-12). These introductions define concepts like commit, repository, clone, branch, rebasing, push/pull/fetch, in more detail than the often superficial overviews you can find online. Many guides left me wondering what these things actually are that these concepts refer to; here their definition is mostly satisfying. The second part of the book ends with a 14th chapter that offers some helpful tips and tricks.
The authors not only show the usage of the commands and options relevant for these topics; they also define topics often encountered in everyday practice and explain in step-by-step guidelines how you would solve them. These are great for initial reference and I think for many of them it's important that you are able to perform the tasks by heart.
The rest of the book is structured around so-called workflows. Personally, I was surprised by the versatility of possible use cases. I think I learned quite a bit about software-development practices by learning about the proceedings of the practices at hand. For instance, "Mit Forks entwickeln" gives a fascinating insight into how open-source projects are basically run. I suppose it abstracts from the sociological matters of the day-to-day, but I still think I have a better understanding now of how you would contribute. There are also remarks conventions or best practices, like giving Branchs a prefix ("release/", for instance). I have to admit, I wasn't even aware of build tools (like Jenkins), either.
The different overview of possible release schedules were helpful, too. It also comes with an explanation of how to deal with version numbering (see Semantic Versioning for more information). A MAJOR.MINOR.PATCH pattern (as described on semver.org), branches down to the MINOR level and patches as stages on that branch. This made good sense. Branches for inactive releases get deleted.
For some reason I was fascinated by the merge cascade required in case of hot fixes being necessary on older releases (if you are working with parallel releases). The first occurrence of the problem is identified, it's fixed there (via a new hot fix branch), and after it's integrated in the branch for the oldest release, we merge step-by-step to the newest release. There is something soothing about the fact of so much structure in something as intimidating as Git.
To be honest, I thought it was still scary in some respects. For instance, to me it seems quite likely that someone would fix an urgent problem in a current release, in which case the commit should be copied to the first release in which the problem occurs. So far so good. But in this case too you have to perform the merge cascade, but you have to think of setting that `ours` option in the case of the current release, so that the commit is not transferred again to where it already is. Oh, so much to keep in mind. I guess it's good I have the book as reference.
The book offers some comfort features that make it easier to actively work with it. At the end of the book, there are overviews of all the workflows and throughout there are cross-references to upcoming or previous sections in which relevant concepts or procedures are explained in more detail. The diagrams often help to visualize more complex workflows, for instance about the relations between Workspace, Stage and Repository, and how file changes, `add` and `commit`a influence them.
There are also sections that explain why the particular way of doing things was chosen, and why it's preferable to alternatives. This helped to get a quick overview of what else it out there, in case you want to decide to dig deeper. To some extent it also explains why the developers of Git set things up the way they did. For instance, there is a section on why you would use the initially cumbersome-looking 40-digit hex code to represent commits.
To my mind, not all practices were perfectly motivated. For instance, I struggled to grasp the importance of stashing. If you are interrupted during your work, your half-finished code is already in the workspace, so why would you store it before tackling a different task (like fixing a bug)? And what is included in a so-called stash? The changes since the last commit? And includes the next commit the changes between the last commit and the stashing (i.e. only the work on the current task)? And does the stashing influence the workspace, are files resetted similarly to what happens when you issue a `reset` command? Of course, you can always look up these concepts online, but I'm under the impression that the book could have been them a more illuminating treatment.
I also struggled to visualize how rebasing fixes the diamond-like history structure. Is the idea that the diamond structure is already the result of the subpar practice of solving conflicts in parallel development by merges rather than by debasing (as suggested by the summary)? Moreover, there were some manners of speaking that I thought were misleading: "Der Ursprung beim `rebase`-Befehl muss nicht unbedingt ein Branch sein. Es kann auch ein beliebiges Commit angegeben werden." Isn't it obvious that the origin is a commit (the base), while it's usually braches that are rebased (moving the point at where the branching happens)? Eventually, rebasing left me thinking, is the cleaning up really worth all the hassle? I struggled to understand the details of the issues and was left even more worried and uncertain about the use of Git than I was before I even knew about the feature. Well, it's obviously used in reality, so it's good that there are the tips about best practices.
I think it's points like the latter that make clear that Git is not the kind of topic you could learn by only reading about it. You have to actively work with the system to develop a proper understanding of what is going on. To be honest, I feel you really have to take extensive notes to remember all the things for future reference, at least until you have thoroughly internalized what is the most important for your personal workflow. In many respects, the book at hand is great for future reference, though. Good choice if you want to learn more about version control and Git!
Rating: 4/5
Until reading this book, there was very little structure to my use of the version control system. I looked up commands online, tried to ignore details (like the upstream option), and hoped that pushes and pulls would get through (don't get me started on branches!). If not I somehow managed to get around by trial and error (and by following the suggestions on Git's excellent command-line advice). Alien concepts, like "origin" or "main", I tried to ignore. Not exactly a great user experience, and certainly nothing you could get away with in a more professional setting.
The first two or three chapters (depending on whether you are interested in the GUI approach) give a concise overview of the core concepts before explaining them in individual chapters (4-12). These introductions define concepts like commit, repository, clone, branch, rebasing, push/pull/fetch, in more detail than the often superficial overviews you can find online. Many guides left me wondering what these things actually are that these concepts refer to; here their definition is mostly satisfying. The second part of the book ends with a 14th chapter that offers some helpful tips and tricks.
The authors not only show the usage of the commands and options relevant for these topics; they also define topics often encountered in everyday practice and explain in step-by-step guidelines how you would solve them. These are great for initial reference and I think for many of them it's important that you are able to perform the tasks by heart.
The rest of the book is structured around so-called workflows. Personally, I was surprised by the versatility of possible use cases. I think I learned quite a bit about software-development practices by learning about the proceedings of the practices at hand. For instance, "Mit Forks entwickeln" gives a fascinating insight into how open-source projects are basically run. I suppose it abstracts from the sociological matters of the day-to-day, but I still think I have a better understanding now of how you would contribute. There are also remarks conventions or best practices, like giving Branchs a prefix ("release/", for instance). I have to admit, I wasn't even aware of build tools (like Jenkins), either.
The different overview of possible release schedules were helpful, too. It also comes with an explanation of how to deal with version numbering (see Semantic Versioning for more information). A MAJOR.MINOR.PATCH pattern (as described on semver.org), branches down to the MINOR level and patches as stages on that branch. This made good sense. Branches for inactive releases get deleted.
For some reason I was fascinated by the merge cascade required in case of hot fixes being necessary on older releases (if you are working with parallel releases). The first occurrence of the problem is identified, it's fixed there (via a new hot fix branch), and after it's integrated in the branch for the oldest release, we merge step-by-step to the newest release. There is something soothing about the fact of so much structure in something as intimidating as Git.
To be honest, I thought it was still scary in some respects. For instance, to me it seems quite likely that someone would fix an urgent problem in a current release, in which case the commit should be copied to the first release in which the problem occurs. So far so good. But in this case too you have to perform the merge cascade, but you have to think of setting that `ours` option in the case of the current release, so that the commit is not transferred again to where it already is. Oh, so much to keep in mind. I guess it's good I have the book as reference.
The book offers some comfort features that make it easier to actively work with it. At the end of the book, there are overviews of all the workflows and throughout there are cross-references to upcoming or previous sections in which relevant concepts or procedures are explained in more detail. The diagrams often help to visualize more complex workflows, for instance about the relations between Workspace, Stage and Repository, and how file changes, `add` and `commit`a influence them.
There are also sections that explain why the particular way of doing things was chosen, and why it's preferable to alternatives. This helped to get a quick overview of what else it out there, in case you want to decide to dig deeper. To some extent it also explains why the developers of Git set things up the way they did. For instance, there is a section on why you would use the initially cumbersome-looking 40-digit hex code to represent commits.
To my mind, not all practices were perfectly motivated. For instance, I struggled to grasp the importance of stashing. If you are interrupted during your work, your half-finished code is already in the workspace, so why would you store it before tackling a different task (like fixing a bug)? And what is included in a so-called stash? The changes since the last commit? And includes the next commit the changes between the last commit and the stashing (i.e. only the work on the current task)? And does the stashing influence the workspace, are files resetted similarly to what happens when you issue a `reset` command? Of course, you can always look up these concepts online, but I'm under the impression that the book could have been them a more illuminating treatment.
I also struggled to visualize how rebasing fixes the diamond-like history structure. Is the idea that the diamond structure is already the result of the subpar practice of solving conflicts in parallel development by merges rather than by debasing (as suggested by the summary)? Moreover, there were some manners of speaking that I thought were misleading: "Der Ursprung beim `rebase`-Befehl muss nicht unbedingt ein Branch sein. Es kann auch ein beliebiges Commit angegeben werden." Isn't it obvious that the origin is a commit (the base), while it's usually braches that are rebased (moving the point at where the branching happens)? Eventually, rebasing left me thinking, is the cleaning up really worth all the hassle? I struggled to understand the details of the issues and was left even more worried and uncertain about the use of Git than I was before I even knew about the feature. Well, it's obviously used in reality, so it's good that there are the tips about best practices.
I think it's points like the latter that make clear that Git is not the kind of topic you could learn by only reading about it. You have to actively work with the system to develop a proper understanding of what is going on. To be honest, I feel you really have to take extensive notes to remember all the things for future reference, at least until you have thoroughly internalized what is the most important for your personal workflow. In many respects, the book at hand is great for future reference, though. Good choice if you want to learn more about version control and Git!
Rating: 4/5
September 30, 2018
Now that's an introductory book I'd recommend!
The easy to follow structure allows to start with what you really need to get a foot into using the reviewed tool. From there on the reader is lead further and further down the road to proper usage and deeper understanding, technically and professionally.
The authors are critical, enthusiastic and fair. Hence, all in all, five of five for this book.
The easy to follow structure allows to start with what you really need to get a foot into using the reviewed tool. From there on the reader is lead further and further down the road to proper usage and deeper understanding, technically and professionally.
The authors are critical, enthusiastic and fair. Hence, all in all, five of five for this book.
March 25, 2015
In diesem Buch werden Arbeitsmethoden erklärt und nicht die einzelnen Funktionen von Git. Daher ist es genau richtig als Ergänzung zu den Cheatsheets, der bei Git hervorragenden internen Hilfe und den funktionsorientierten Online-Dokumentationen.
February 25, 2013
Gutes und praxisnahes Buch inkl. Vermittlung der Grundlagen.
Displaying 1 - 4 of 4 reviews