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== | ||
− | + | {{w|Git (software)|Git}} is a version control system, used to manage the code in many thousands of open source software projects. It is very powerful, and was amongst the first widely adopted tools to use a distributed version control model (the "beautiful [https://en.wikipedia.org/wiki/Graph_theory graph theory] [https://en.wikipedia.org/wiki/Tree_(graph_theory) tree model]"), meaning that there is no single central repository of code. Instead, users share code back and forth to synchronise their repositories, and it is up to each project to define processes and procedures for managing the flow of changes into a stable software product. | |
− | {{w|Git (software)|Git}} is a version control system, used to manage the code in many | ||
− | + | Although very powerful, the command line of Git is notoriously difficult to learn and master. Dozens of blog posts and websites (see [http://think-like-a-git.net/epic.html], [http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/]), and even books ([http://blog.anvard.org/conversational-git/chapter-01.html], [http://git-scm.com/book/en/v2]) have been written to help users navigate this complexity. | |
− | Although very powerful, the command line of Git is notoriously difficult to master. Dozens of blog posts and websites (see [http://think-like-a-git.net/epic.html], [http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/]), and even books ([http://blog.anvard.org/conversational-git/chapter-01.html], [http://git-scm.com/book/en/v2]) have been written to help users navigate this complexity. | ||
− | The difficulty of using Git in common situations is | + | The difficulty of using Git in common situations is belied by the apparent simplicity of its use in tutorial-style situations. Committing and sharing changes is fairly straightforward, for instance, but recovering from situations such as accidental commits, pushes or bad merges is difficult without a solid understanding of the rather large and complex conceptual model. For instance, three of the top five highest voted questions on StackOverflow are questions about how to carry out relatively simple tasks: undoing the last commit, changing the last commit message, and deleting a remote branch. |
− | This comic thus explores the difference between the idealised view of Git's architecture, and its actual typical usage. Tutorials for | + | This comic thus explores the difference between the idealised view of Git's architecture, and its actual typical usage. Tutorials for git tend to use simple systems in their examples, and only deal with the most basic commands to get started, which can create the misleading impression that git can be used effectively without extensive study. |
− | Due to this problem, compounded by the fact that | + | Due to this problem, compounded by the fact that git's commands are named differently from similar commands in other version control systems, many users (including Cueball) 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. |
− | |||
Cueball suggests "just memoriz[ing] these shell commands and type them to sync up". He is probably referring to a sequence of commands such as: | Cueball suggests "just memoriz[ing] these shell commands and type them to sync up". He is probably referring to a sequence of commands such as: | ||
Line 29: | Line 26: | ||
git push | git push | ||
− | |||
As long as every contributor to the project follows these principles, this may suffice for a while. But many situations may cause "errors": | As long as every contributor to the project follows these principles, this may suffice for a while. But many situations may cause "errors": | ||
Line 36: | Line 32: | ||
* attempting to recover from a situation such as an accidental merge, and making the situation worse. | * attempting to recover from a situation such as an accidental merge, and making the situation worse. | ||
− | In a | + | In a stiuation such as a merge conflict, Git will show an error message such as: |
CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree. | CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree. | ||
# Automatic merge failed; fix conflicts and then commit the result. | # Automatic merge failed; fix conflicts and then commit the result. | ||
− | |||
Although Git experts can of course deal with such situations, the remedy proposed by Cueball is "save your work elsewhere, delete the project, and download a fresh copy". That is, to copy the files out of their local repository's working directory, delete that whole structure, then clone the remote repository again (and, implicitly, copy the saved work back again): | Although Git experts can of course deal with such situations, the remedy proposed by Cueball is "save your work elsewhere, delete the project, and download a fresh copy". That is, to copy the files out of their local repository's working directory, delete that whole structure, then clone the remote repository again (and, implicitly, copy the saved work back again): | ||
Line 60: | Line 55: | ||
Abandoning the old project likely means losing some work, but may be faster and give a more predictable outcome than attempting to salvage the situation. Applying this method to a mere merge conflict issue may prolong the issue however, as the merge conflicts may still be present. | Abandoning the old project likely means losing some work, but may be faster and give a more predictable outcome than attempting to salvage the situation. Applying this method to a mere merge conflict issue may prolong the issue however, as the merge conflicts may still be present. | ||
− | + | The title text suggests an alternative method for working around Git's complexities, which reflects common practice: knowing a "Git expert" who can help in any situation. Such experts are somewhat notorious for waxing lyrically about Git's strengths, so it may be necessary to win their favour by first letting them ramble enthusiastically about it. They will hopefully eventually give the exact commands needed. In practice, the question-and-answer site StackOverflow.com is frequently used for this exact purpose. | |
− | The title text suggests an alternative method for working around Git's complexities, which reflects common practice: knowing a "Git expert" who can help in any situation. Such experts are somewhat notorious for waxing lyrically about Git's strengths, so it may be necessary to win their favour by first letting them ramble enthusiastically about it. They will hopefully eventually give the exact commands needed. In practice, the question-and-answer site | ||
− | It may even be a reference to the infamous tweet "[https://twitter.com/agnoster/status/44636629423497217 | + | It may even be a reference to the infamous tweet "[https://twitter.com/agnoster/status/44636629423497217 git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space]" which has since been [http://www.beyondjava.net/blog/git-explained-in-really-simple-words/ debunked as nonsense]. |
− | Putting a telephone number of someone who "understands | + | 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 | *Software teams would more normally use electronic means of communication | ||
− | *Explaining | + | *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 | + | *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. |
− | |||
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 (although Git also offers a large number of nontrivial benefits over standard version control systems, which is why it is used). 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 (although Git also offers a large number of nontrivial benefits over standard version control systems, which is why it is used). Cueball is one of those programmers. | ||
− | + | The comic [[1296]] also features git. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | The comic [[1296 | ||
==Transcript== | ==Transcript== | ||
Line 94: | Line 78: | ||
[[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]] |
− |