Git is a distributed version control system (DVCS) written in C. A version control system allows the creation of a history for a collection of files and includes the functionality to revert the collection of files to another state. Another state might be a different collection of files or different content in the files.
You may, for example, change the collection of files to a state from 2 days ago or you may switch between states for experimental features and production issues.
The collection of files is usually called "source code". In a distributed version control system everyone has a complete copy of the source code (including the complete history of the source code) and can perform version control operations against this local copy. The use of a DVCS does not require a central code repository.
If you make changes to the source code you mark them as relevant for the version control (add them to the index / staging) and then add them to the repository (commit).
Git maintains all versions. Therefore you can revert to any point in your source code history using Git.
Git performs commits to your local repository and you can synchronize your repository with other (remote) repositories. Git allows you to clone repositories, e.g. create an exact copy of a repository including the complete history of the source code. Owners of repositories can synchronize changes via push (transferring changes to a remote repository) or pull (getting changes from a remote repository).
Git supports branching, e.g. you can have different versions of your source code. If you want to develop a new feature, you may open a branch in your source code and make the changes in this branch without affecting the main line of your code.
Git can be used from the command line. You also find graphical tools, for example EGit for the Eclipse IDE.
Git requires that changes are marked explicitly for the next commit. For example, if you make a change in a file and want that this change is relevant for the next commit, you have to add the file to the so-called "staging index" via the git add file command. The staging index will be a complete snapshot of the changes.
New files must always be explicitly added to the index. For files that have already been committed, you can use the -a flag during a commit.
You may, for example, change the collection of files to a state from 2 days ago or you may switch between states for experimental features and production issues.
The collection of files is usually called "source code". In a distributed version control system everyone has a complete copy of the source code (including the complete history of the source code) and can perform version control operations against this local copy. The use of a DVCS does not require a central code repository.
If you make changes to the source code you mark them as relevant for the version control (add them to the index / staging) and then add them to the repository (commit).
Git maintains all versions. Therefore you can revert to any point in your source code history using Git.
Git performs commits to your local repository and you can synchronize your repository with other (remote) repositories. Git allows you to clone repositories, e.g. create an exact copy of a repository including the complete history of the source code. Owners of repositories can synchronize changes via push (transferring changes to a remote repository) or pull (getting changes from a remote repository).
Git supports branching, e.g. you can have different versions of your source code. If you want to develop a new feature, you may open a branch in your source code and make the changes in this branch without affecting the main line of your code.
Git can be used from the command line. You also find graphical tools, for example EGit for the Eclipse IDE.
Git requires that changes are marked explicitly for the next commit. For example, if you make a change in a file and want that this change is relevant for the next commit, you have to add the file to the so-called "staging index" via the git add file command. The staging index will be a complete snapshot of the changes.
New files must always be explicitly added to the index. For files that have already been committed, you can use the -a flag during a commit.
0 comments:
Post a Comment