The main thing to know is that this is not an all-or-nothing decision and it’s a relatively easy decision to revisit later.Īnother advantage of HTTPS is that the PAT we’ll set up for that can also be used with GitHub’s REST API. I started with HTTPS, preferred SSH for a while, and have returned to HTTPS. The “ease of use” argument in favor of HTTPS is especially true for Windows users. HTTPS is what GitHub recommends, presumably for exactly the same reasons. I find HTTPS easier to get working quickly and strongly recommend it when you first start working with Git/GitHub. The recommendation to use a personal access token (PAT) is exactly what we cover in this chapter. Please use a personal access token instead. Here’s the error you’ll see if you try to do that now: remote: Support for password authentication was removed on August 13, 2021. You can learn more in their blog post Token authentication requirements for Git operations. This was possible in the past (and may yet be true for other Git servers), but those days are over at GitHub. Let it be known that the password that you use to login to GitHub’s website is NOT an acceptable credential when talking to GitHub as a Git server. Head over to chapter 10 if you really want to set up SSH keys. With HTTPS, we will use a personal access token (PAT). Here we describe the credential setup for the HTTPS protocol, which is what we recommend if you have no burning reason to pick SSH. Git can communicate with a remote server using one of two protocols, HTTPS or SSH, and the different protocols use different credentials. This proves we are a specific GitHub user, who’s allowed to do whatever we’re asking to do. When we interact with a remote Git server, such as GitHub, we have to include credentials in the request.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |