![]() ![]() ![]() 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. 5 Altering history (and potentially creating bigger problems).4.1 fatal: detected dubious ownership in repository.3.6 Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched.3.5 error: You have not concluded your merge (MERGE_HEAD exists).3.4.2 Your branch is behind 'origin/master' by 8 commits, and can be fast-forwarded.3.4.1 "Your local changes to the following files would be overwritten by merge".3.3 Resolving conflicts (also: undoing things).2.5.4 On using someone's existing branches.2.2 Starting to work with versioned code.1.2.2 "For those coming from other versioning systems.".1.1.3 Everyday operations, everyday tasks.1.1 Mental model, and "For those coming from other versioning systems.".
0 Comments
Leave a Reply. |