![]() ![]() provide us with a backup copy in case our laptop gets hit by a bus.usually live somewhere (like GitHub) that has a nicer interface for us to navigate the app at different points in history.So, we often link our local repos to a remote repo! Remote repos: if your computer gets hit by a bus, the whole app is gone.it’s hard to dig into your past commits and really see the history of your app so that you can make use of the version control - if you wanted to go back to a particular state of you application, it would be a little trickier to navigate there from the terminal when you can’t really see what the codebase looks like at each one of the previous commits.Though local repos provide you with full-blown version control, there are still some limitations: So the important thing to remember here is that your files aren’t actually considered to be a part of your local repo until you’ve committed them. the local repo: any files that you’ve actually committed to your local repo by running git commit.the staging area: any files or changes to those files that you’ve made git aware of by running git add.the working directory: this has any files you’ve created that git is not yet aware of.Given the workflow we just walked through, we can identify 3 separate environments or phases of working locally: If we were to try to push this up to GitHub somewhere, nothing would appear. Notice if you do a git log, you still don’t have any commits to you local repo, so your local repo is still considered empty right now. It holds onto any file changes that you are considering committing to your local git repo. This phase right here is called your staging area. If we follow the instructions here and we do a git add, we see that file is now highlighted in green instead of red, and git is now aware of it as something that can be committed. This means that git can tell there’s a file in your current working directory, but it’s not keeping an eye on it yet. You should see that you have a single untracked file. So if you were to add files to this directory, we would be able to track any future changes to them.Īdd a file to your directory, then run a git status. We have no remote repository associated with this local git repository just yet, it simply lives on our machine and gives us all the version control features of git. Now run git init – you’ve just created a local git repository! In your terminal, create a new directory and cd into it. Local repos live on our machines and allow us the full benefit of git’s version control. our remote repo - which lives on GitHub, where anyone can view our files and clone or fork their own local copy.We cd into a project directory and edit our code files, we run git add and git commit on them, etc. our local repo - which lives on our machine, where we make our changes and do our development.When we’re working with git and GitHub, we usually have 2 repos that represent the same codebase: link remotes to your local repositories.choose the appropriate method for copying a repo.articulate the difference between forking and cloning.articulate the difference between your remote and local repos.Local Repo A repository on your machine that allows you to version control a directoryīy the end of this lesson, you will be able to:.Remote Repo A repository on the web that allows others to view and contribute to your code.Forking Creating your own copy of somebody else’s repo. ![]() ![]() Cloning Copying a remote repo to your local machine.Git A distributed version control system.Git Review - remotes/locals and forking/cloning ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |