Editing 1597: Git
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
− | |||
− | |||
− | + | This comic is a play on how git, a popular version control system, is misused by people who have a very poor understanding of its inner workings. Git is a particularly apt target for such a joke due to its widespread use and the significant discrepancy between its perceived complexity and its simple underlying design. Tutorials for git tend to make extensive use of a cozy bootstrap layout and deal only with the most basic commands to get started, which can create the misleading impression that git can be used effectively without extensive study. As this is rarely the case, a large group of git users (including Cueball) have a knowledge of git that extends to memorizing a set of commands rather than a conceptual understanding of what those commands actually do. As this behaviour can easily lead to a corrupt repository, Cueball suggests that Ponytail keeps an alternative copy of her project outside git which, of course, defeats the purpose of employing a version control system to begin with. | |
− | |||
− | + | {{w|Git (software)|Git}} is a {{w|Version control|version control}} system often used to track changes to (usually) plain text files, such as computer code. Within a folder and its subfolders, the user can tell git which files to keep track of changes for. All the files that are being tracked in this manner make up a repository. Internally, git works by saving the differences between different versions of the files, so that the same file content is only stored once, rather than creating a new copy each time the user "commits" the current version of the code. This approach allows the user to switch between various versions of the code fairly quickly. However, this can be confusing for new users because when changing between versions, git effectively rewrites the files under its control to match that version - one file may have several different versions depending on which state git has set it to, but only one of these versions is visible at any given moment. The others are not hidden or moved: any given version of a file does not exist as a single, complete file unless that version is currently active. | |
− | + | In addition to allowing the user to track changes to the files over time using "commits" (versions of the files stored by the user), git also allows the user to develop several versions of the files in parallel using "branches" (mentioned in the title text). This allows a programmer to, for example, keep a stable, functioning version of their code in one branch, while developing a new feature in a separate branch. When the new feature is ready, git provides tools to efficiently "merge" the changes from the development branch back into the main branch. While powerful, there are also several pitfalls which can confuse users. For example, a file may have only been committed in one branch (so it is only visible in that branch), causing a user who has switched to a different branch to think that file was lost somehow. | |
− | + | Although git is completely distributed in principle, so that every "clone" (full working copy) of a repository is independent of all others, many programming teams use remote repositories, sometimes hosted on services like {{w|GitHub}} or {{w|GitLab}}, or on private servers, to collaborate on projects. This remote repository acts as a central location through which collaborators share their work. Changes do not automatically propagate between users; instead, once someone has changes they are ready to share, they must upload ("push" in git terminology) their changes to the remote repository. Other users can then download ("pull") those changes. This allows each user complete control over when changes are applied to their version of the files. Once one user has pushed his or her changes, all other users will need to merge those changes into their code before they can push. Depending on how much the changes conflict, git may be able to automatically combine both users' versions, or the user may need to do so manually. Problems often arise when, for example, one programmer attempts to upload changes to a file someone else has already edited. | |
− | + | One way of simplifying collaboration is to work in a private "branch" that is not used by other collaborators. All branches independently track their changes and can be viewed independently of each other. Only when you successfully "merge" individual branches together will you see other collaborators' "commits" in your working set of files. | |
− | |||
− | + | Due to the complex nature of git (and its notoriously counter-intuitively named commands), a large proportion of its users are unable to use it beyond basic commands, and might try to avoid problems by saving their code outside git, downloading a newer copy, and then re-applying their changes to the new copy instead of trying to understand and use the features that exist in git to simplify this task. | |
− | |||
− | |||
− | |||
− | |||
− | + | The git.txt refers probably to a habit of some development teams to put readme-like instructions into a simple text file into the project. These are usually helpful for special tasks like creating databases, or dealing with unusual quirks of the project. Its use here is ironic because git should be well understood by developers, as it is a basic tool. Moreover, you have to use git to get the file to be able to read it in the first place. | |
− | |||
− | + | Putting a telephone number of someone who "understands git" into such a file is humorous because: | |
− | * | + | * software teams would more normally use electronic means of communication |
− | * | + | * explaining git over the phone to team members should not be necessary, as there is extensive help available online, and |
+ | * in the situation where many team members would need phone support to avoid or fix basic git problems, this would be extremely distracting to the person whose phone number was given in the file. | ||
− | + | Git was originally created by {{w|Linus Torvalds}}, the same person who originally created {{w|Linux}}. | |
− | + | ==={{w|Wikipedia:Too long; didn't read|tl;dr}}=== | |
− | |||
− | + | The explanation above was written by that friend whose name is in git.txt, and gives a good idea of what you need to wait through before he tells you the commands you need. In short: programmers use {{w|Version control|version control systems}} to track changes to code. Most of these version control systems are quite similar and easy to learn if you already know another one. Git is a version control system based on completely different principles, and most programmers find it difficult to wrap their heads around it. Cueball is one of those programmers. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | In short: programmers use {{w|Version control|version control systems}} to track changes to code. Most of these version control systems are quite similar and easy to learn if you already know another one. Git is a version control system based on completely different principles, and most programmers find it difficult to wrap their heads around it | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Transcript== | ==Transcript== | ||
Line 91: | Line 41: | ||
{{comic discussion}} | {{comic discussion}} | ||
+ | |||
[[Category:Comics featuring Cueball]] | [[Category:Comics featuring Cueball]] | ||
[[Category:Comics featuring Ponytail]] | [[Category:Comics featuring Ponytail]] | ||
[[Category:Comics featuring Hairy]] | [[Category:Comics featuring Hairy]] | ||
+ | [[Category:Programming]] | ||
[[Category:Computers]] | [[Category:Computers]] | ||
− | [[Category: | + | [[Category:Internet]] |
− |