Git – Local Commands

And remote and local copy of a repository

Git is an extremely powerful Distributed Version Control System. And by saying that, I’m getting straight to business.

The “Distributed” part means that there is no central repository on which all developers are working. On the contrary – every developer has a clone of some publicly available (whether on the internet, or at work) repository. The “central” becomes just a place to share your work and pull others’ changes.

This is one of the features that make working with Git very handy. It is also one that people often don’t realize. I’ve heard a lot of conversations like:

– (…) and check in the log who committed that file.
– OK, just need to plug in the network cable.

Well, he does not! You get a full copy of a repository when you clone it, and thanks to it, the following is true:

Most of the git commands that we issue work locally – not only aren’t they trying to reach out to the remote, but you also don’t even need the network connection.

This is also one of the reasons why working with Git is so fast – there is no network overhead. Also, you can keep working even after the remote server is down or unavailable for any reason.

Just a few examples – whenever you do one of the following:

  • git init
  • git config
  • git status
  • git checkout
  • git branch
  • git add
  • git commit
  • git diff
  • git merge
  • git log
  • git reset

You are working on your local copy of the repository. Nothing on the remote repository changes. Keep that in mind.

So when do you actually talk to the remote? Whenever you issue one of the following:

  • git clone
  • git fetch
  • git pull
  • git push

If something ever goes wrong but you haven’t pushed yet, remember – the damage (if any) is only done to your local copy of the repository and can be fixed before sharing your work, so do not worry!

Leave a Reply

Your email address will not be published.