![]() The repository is the only thing that tells you how to refer to each revision (which may be a version counter)Īnd that's really the only kind of "make changes in the system" operation there is The concept of "a chunk of changes" is basically "whatever the difference between this version and what it was in the last version" Working copies can never diverge much from that repository - the more and longer they do, the harder it is to ever exchange with again The only place where things get committed is that central repository. The only place everyone communicates with is that central repository The main alternative is is diverging from is the central repository, where Git is distributed in nature, more specifically a distributed graph, but almost no one uses it quite that way It's a side effect of the distributed graph nature.Īnd when you might want one over another. That's a real difference, but not really the point. "in git, everything is local" is meant to say that every copy is an independent, complete, standalone thing. Which in itself, is local to a copy, not something reflected elsewhere until you make that happen in git's style, a commit basically just identifies an annotated collection of diffs.in respository style, you can intuit a commit as "the new revision that everyone should have"Īnd global to all users of that repository.Perhaps the largest mental switch is that In that diagram, this is what that "somewhat indirectly" hints at.Įveryday operations, everyday tasks But why? Comparing purposes This article/section is a stub - probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. If you don't use those, and aren't Linus, well, it's clunky. Yet it turns out this proposing isn't quite a part of git so it's still sort of out of band,Įxcept that the tooling is nicer - yet specific to the hosting (github, gitlab, etc - it's part of why self hosting is not common).īecause github or gitlab have features that help you here. With git, the habit is still "you don't make a change, you get to propose a change for the dev to look at". Unsolicited were always their own special case, and still are.īefore git people tended to send you a diff via mail and have the you, the developer, figure it out. ![]() (Github even makes you think about restricting collaborators from doing pull requests, and considers this protection ) Sure, you can always give people access to your repo, and this is still fully possible with git, and github, and gitlab.īut the default is to not trust, except maybe if you're a well defined, fully trusting dev team. requiring contributors to do their own squash merges, or rebase merges ) (github considers it protection to require linear history, a.k.a. We avoid the anarchistic structure because when you communicate well, it's more trouble than it's worth.Ĭompanies have a vested interest in communicating more frequently and in more detail than that,Īnd frankly even hobby projects want to avoid messy games of degrees of separation of code, so still often organize with a central repo. It turns out that 99% of uses are actually like: Team contributions versus unsollicited contributions which is fully possible, and a few projects intentionally use something like it (the hierarchical anarchy of the linux kernel project is a really interesting case), but almost nobody else actually does that quite like that - most of us use gitlab or github (sometimes a privately hosted repository) as, well, largely as a central repository but with some extra communication made somewhat easier. Git introductions like to say "every clone is an independent copy", and that means you could do whatever you want, like: Git notably breaks from this central repository / working copy model that many others have. Git does not require a central place that everything synchronizes with - as most others do.Ĭlassic source versioning often only talk via a single central place, like: Mental model, and "For those coming from other versioning systems." Git is a content/source versioning system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |