Cloning is easy to do, provided you’re granted access to the repo on GitHub and you’ve set up your local ssh keys. Although I briefly mentioned cloning earlier in this series, I didn’t describe how it fit together with the ideas of remote repositories. The process of copying the repo is called cloning. Most developer shops will initialize a repo on GitHub from which everyone else will copy the repo to their own machines. In the spirit of the chicken and egg, you have to start a repo somewhere. Since you were second, the remote repo won’t let you overwrite the other developer’s changes. If two people are working on the same file on the same branch, and one person pushes their changes up to the remote repo, and then you push your changes up to the same repo, there’s going to be a clash. Essentially, the changes on your local branch get pushed up and merged into the branch on the remote repo. Your commits will be added to the end of the branch on the remote repo so that the remote branch will be identical to your own branch. You can have a branch on both the remote repo and your own local repo make changes and commit them to your local repo and then push them up to the remote repo. One interesting aspect here, however, is that you can work with existing branches. The remote repo will integrate the branch, just as if it was created in that remote repo itself. You’ll then work on a branch, and then copy that branch back up to the remote repo. However, it’s important to remember that, even with a repository on GitHub, you’re still dealing with individual repositories, and the one on GitHub is just another repo.Ī typical scenario is that you’ll create a remote repository (such as on GitHub) and you’ll copy the repo down to your own computer. On GitHub, you keep another repository with your code, and that’s the one that developers all merge their branches into. That’s where something like GitHub comes in. Git was developed from the ground up for exactly that type of development process.Īlthough there’s technically no central repository, you can still have a repository that you treat as a central repository of sorts. However, by having their own repositories, the developers still need to merge the branches of their repositories together. Unlike older source control systems, there isn’t a central repository from which developers check out their files to work on. The whole idea behind Git is that each developer has their own repository on their own machine. In this final installment on learning Git ( part one is here, followed by part two and part three), we’re going to cover an important topic: Remote repositories, including GitHub.
0 kommentar(er)
