The information returned by this logging command contains the unique hash key (SHA-1) representing each commit, the author and date of the commit and also the commit message. This list is synchronized with the remote repository when pushing/ pulling/ cloning. Returns the stack-like formatted list of commits in the local repository. During a rebase, you may encounter conflicts which have to be resolved manually. Merges you local commits with commits from the remote repository by first applying remote commits and then applying your commits on top. Gets the latest changes from the remote repository when a cloned snapshot is already on the local machine. Gets a snapshot of the remote repository on the local machine. Sometimes, if you are coding in an IDE there are plug-ins or add-ons to integrate the use of Git in your development environment. The following commands are usually entered in the command line, but as there are visual tools that allow not only to visualize but also to operate on the repository, these commands are present also in the GUI clients. In order to visualize the changes between the local repository version and the latest changes added to the files in the workspace, we can use a difference viewer that can display differences to the local repository (committed changes) or to the local index (modified but not committed to the repository yet ). After modifying the files the procedure repeats itself, by adding and committing the changes to the local repository and then if needed to the remote repository.
The entries are saved with a timestamp for sequencing them time and with a hash (SHA-1) for their internal storage in Git.
The commits are stored in a stack like structure in the repository (local/remote) and you can access the latest change reference (HEAD) or any of the earlier entries. If there is something that you are not sure that it should be pushed to the remote repository but it is committed in your local repository, you can check out the specific commit (changeset) and rework it, by reverting the commit. If you had already a local copy, in order to get the latest snapshot of the remote repository you just need to fetch it.Īssuming that you added some changes in the local repository files and you want to make these changes recorded in the remote repository, as to be available for others or as a major change to be recorded the following procedure must be performed.įirst, add the modified files to the local index (stage), commit them to the local repository and then push them into the remote repository. This operation can be performed by cloning the remote repository. If the remote repository is populated with files the first step is to get a snapshot of your remote repository on your local machine, so that you will get a working copy on your machine. Right now the remote repository has the same contents as you local repository. When everything is committed in the local repository you simply push the files into the remote repository. The local repository has the same structure as the remote repository. If the remote repository is empty (not populated with files yet) you have to add the files you want in your project from your workspace to the local index (keeps a record of repository files, also called stage) and then commit them to the local repository. Git is a fully distributed version control system, widely used because of its speed, efficiency in handling large projects and the powerful branching mechanism which ensures a good management of many parallel branches.Īssuming you have a repository (empty or not) on a remote server accessible via Internet or a local network. The generic architecture of a distributed version control system: The core of the version control system is the repository.
0 kommentar(er)
