Book Image

Mastering Git

5 (1)
Book Image

Mastering Git

5 (1)

Overview of this book

Git is one of the most popular types of Source Code Management (SCM) and Distributed Version Control System (DVCS). Despite the powerful and versatile nature of the tool enveloping strong support for nonlinear development and the ability to handle large projects efficiently, it is a complex tool and often regarded as “user-unfriendly”. Getting to know the ideas and concepts behind the architecture of Git will help you make full use of its power and understand its behavior. Learning the best practices and recommended workflows should help you to avoid problems and ensure trouble-free development. The book scope is meticulously designed to help you gain deeper insights into Git's architecture, its underlying concepts, behavior, and best practices. Mastering Git starts with a quick implementation example of using Git for a collaborative development of a sample project to establish the foundation knowledge of Git operational tasks and concepts. Furthermore, as you progress through the book, the tutorials provide detailed descriptions of various areas of usage: from archaeology, through managing your own work, to working with other developers. This book also helps augment your understanding to examine and explore project history, create and manage your contributions, set up repositories and branches for collaboration in centralized and distributed version control, integrate work from other developers, customize and extend Git, and recover from repository errors. By exploring advanced Git practices, you will attain a deeper understanding of Git’s behavior, allowing you to customize and extend existing recipes and write your own.
Table of Contents (19 chapters)
Mastering Git
Credits
About the Author
About the Reviewer
www.PacktPub.com
Preface
Index

Amending history without rewriting


What to do if what you need to fix is in the published part of the history? As described in Perils of rewriting published history section, changing the parts of the history that were made public (which is actually creating a changed copy and replacing references) can cause problems for downstream developers. You better not to touch this part of the graph of revisions.

There are a few solutions to this problem. The most commonly used is to put a new fixup commit with appropriate changes (for example, a typo fix in a documentation). If you need to remove changes, deciding that they turned out to be bad to have, you can create a commit to revert the changes.

If you fix a commit or revert one, it would be nice to annotate that commit with the information that it was buggy, and which commit fixed (or reverted) it. Even though you cannot (should not) edit the fixed commit to add this information if the commit is public, Git provides a notes mechanism to append...