[{"_1":2,"_42":-5,"_43":-5},"loaderData",{"_3":4,"_10":11,"_40":-5,"_41":-5},"root",{"_5":-5,"_6":-5,"_7":-5,"_8":9},"user","shoppingCartId","toast","locale","en","routes/_store+/_readers+/email_author.$slug/route",{"_12":13,"_39":-5},"book",{"_14":15,"_16":17,"_18":19,"_20":21,"_22":23,"_24":25},"id","Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6Qm9va1Byb2R1Y3QvNTY5NDY","title","GIT intermediate","state","published","contactAuthorMethod","email","aboutText","

Find also a paperback edition available on Amazon.

Discover the inner beauty and elegance of Git! Learn to create decent, professional repositories!

Bearing the proper abstractions in mind, you know why and what should be done; It is easier then, to find the answer to how to do it.

“GIT intermediate” gives the reader a good sense of Git’s mechanics, how it really works. It is particularly useful when less obvious situations occur.

At first glance, Git looks like a tangle of strange commands with incomprehensible parameters. The documentation is hard to read, so the entry threshold seems high. This creates a natural temptation to scrape the bottom of the barrel: to learn just a few operations (performed from command line, graphical tool or IDE) typical of the team’s workflow.

As a result, the repository is cluttered with project versions of poor quality, many of which do not meet established standards. E.g.:

„Under construction” versions: The changes committed „before lunch”, before and after code review, etc. Ok, one can improve it a bit by using --squash option.
Many incoherent changes in one version: Changes that are hard to review/understand; hindering extracting/reverting parts of them.

Is really such a cluttered repository good enough for a professional team in 2023?

Should really „just merge the branch” approach be your way? Or should you rather care of individual commits?

“GIT intermediate” is short.

On 100 pages of loose A4 text, the book — often in an experimental way — introduces into the world of Git’s abstracts and gives practical knowledge, illustrated by examples.

There are a few main entities that need to be captured to have a good sense of Git’s mechanics. These are:

Repository as a commit graph.
Refs (of any kinds) as tools for graphs growing (both local and remote).
Immutability of the graph vs history rewriting (transplanting of the commits).
Cooperation between local and remote repository as sharing of the subgraphs.

The metaphors of all these entities fit on the front cover! Can you recognize them?

See a short YouTube session: Making the front cover.

They say why and what should be done. The author demystifies the often misunderstood things, explaining how things can be done:

commit
index/staging area
reset
rebase
fast-forward-merge
merge conflicts

The book can be read as “from zero to hero” guide. Nevertheless, after months/years of using Git, it is practical to take a break and return to the roots, from time to time.

The topics covered are illustrated with examples and contain links to the documentation. Advanced issues (e.g. refspec) and extensive issues (e.g. git log) are described synthetically, with an indication of interesting issues and references to the appropriate parts of the documentation.

The repetitions are intentional, they are intended to help the reader remember the proper abstractions.

","authors",[26],{"_14":27,"_28":29,"_5":30},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci82MDA1OA","name","Jacek Drąg",{"_31":32},"avatar",{"_33":34,"_35":36,"_37":38},"url","https://d308did4coypzi.cloudfront.net/avatars/2732892/medium/jacek-2023.jpg?1698606157","styleName","medium","exists",true,"currentUser","routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Email the author