Documenting Proper Git Usage

git emblem

Jonathan Corbet wrote a document for inclusion in the kernel tree, describing
best practices for merging and rebasing git-based kernel repositories. As he put
it, it represented workflows that were actually in current use, and it was a living
document that hopefully would be added to and corrected over time.

The inspiration for the document came from noticing how frequently Linus
Torvalds

was unhappy with how other people—typically subsystem maintainers—handled
their git trees.

It's interesting to note that before Linus wrote the git tool, branching and
merging was virtually unheard of in the Open Source world. In CVS, it was a
nightmare horror of leechcraft and broken magic. Other tools were not much better.
One of the primary motivations behind git—aside from blazing speed—was, in
fact, to make branching and merging trivial operations—and so they have become.

One of the offshoots of branching and merging, Jonathan wrote, was rebasing—altering the patch history of a local repository. The benefits of rebasing are
fantastic. They can make a repository history cleaner and clearer, which in turn
can make it easier to track down the patches that introduced a given bug. So
rebasing has a direct value to the development process.

On the other hand, used poorly, rebasing can make a big mess. For example, suppose
you rebase a repository that has already been merged with another, and then merge
them again—insane soul death.

So Jonathan explained some good rules of thumb. Never rebase a repository that's
already been shared. Never rebase patches that come from someone else's repository.
And in general, simply never rebase—unless there's a genuine reason.

Since rebasing changes the history of patches, it relies on a new „base“ version,
from which the later patches diverge. Jonathan recommended choosing a base version
that was generally thought to be more stable rather than less—a new version or a
release candidate, for example, rather than just an arbitrary patch during regular
development.

Jonathan also recommended, for any rebase, treating all the rebased patches as new
code, and testing them thoroughly, even if they had been tested already prior to
the rebase.

„If“, he said, „rebasing is limited to private trees, commits are based on a
well-known starting point, and they are well tested, the potential for trouble is
low.“

Moving on to merging, Jonathan pointed out that nearly 9% of all kernel commits
were merges. There were more than 1,000 merge requests in the 5.1 development cycle
alone.



Source

Veröffentlicht von Paul Christoph

Mein Name ist Paul Christoph Feichtinger, geboren am 15.5.1991 in Oberndorf bei Salzburg und mittlerweile stolzer Autor von 11 Büchern (7 in Deutsch und 4 in Englisch), 4 Apps (bald kommt Nummer 5) und dieser Webseite. Bei Paul Solutions bekommen alle Bücher und Apps ihre Form. Sieh dich ruhig ein bisschen auf meiner Webseite um, vielleicht gibt es auch für dich noch das ein oder andere zu entdecken. ;-)

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

%d Bloggern gefällt das: