Difference between revisions of "Introduction to Git"
Elcwikiadmin (talk | contribs) |
Elcwikiadmin (talk | contribs) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
* When working in a team, there will be a centrally accessible primary repository that all users upload new changes to, and download other people's changes from | * When working in a team, there will be a centrally accessible primary repository that all users upload new changes to, and download other people's changes from | ||
* You can choose when you synchronize you local copy of the files with the primary repository | * You can choose when you synchronize you local copy of the files with the primary repository | ||
| − | * When a developer wants to control who changes the contents of the primary repository, | + | * When a developer wants to control who changes the contents of the primary repository, they can make it read only so only new changes can be downloaded |
| + | |||
| + | A few important pieces of Git terminology and their roles in the workflow: | ||
| + | |||
* The process of downloading new changes from a central repository is called a "pull" | * The process of downloading new changes from a central repository is called a "pull" | ||
* The process of uploading new changes to a central repository is called a "push" | * The process of uploading new changes to a central repository is called a "push" | ||
| Line 17: | Line 20: | ||
* When you make changes to your local copy of the repository, these changes are not tracked until you "commit" them. | * When you make changes to your local copy of the repository, these changes are not tracked until you "commit" them. | ||
* Only changes that have been "committed" can be "pushed" or "pulled" to or from a central repository | * Only changes that have been "committed" can be "pushed" or "pulled" to or from a central repository | ||
| − | * Before you "push" or "pull" any changes, | + | * Before you "push" or "pull" any changes, your local repository must have no uncommitted changes. |
=Using Tortoise Git= | =Using Tortoise Git= | ||
| + | Tortoise Git is great if you're working in a Windows environment as is integrates with the Shell context menu for explorer. When a folder is controlled by Git, you can either Right-click on or inside a Windows Explorer folder to access the various operations you want to carry out. | ||
| + | :[[Image: GitShell.png|800px]] | ||
===Cloning a Repository=== | ===Cloning a Repository=== | ||
| − | + | To clone a central repository either from an online or local location, the Git->Clone command is used. This creates an exact copy of the repository and automatically references the central repository to your local repository as a "remote" allowing you to "pull" new changes and "push" your changes if you have "write" access to the central repository. | |
| + | |||
| + | If you are cloning a Git repository from an online location like this Wiki or Github, you will be provided with a "clone URL". This is the online address of the repository. | ||
| − | + | With Tortoise Git you can use the following steps: | |
| + | # Navigate to a folder in Windows explorer where you would like the repository to kept | ||
| + | # Right-Click to bring up the context menu | ||
| + | #: [[Image: GitCloneContext.png|600]] | ||
| + | # Choose "Git Clone" | ||
| + | # Enter the repository location in the appropriate field. This is a URL for online locations but can also be a local file system address | ||
| + | #: [[Image: GitCloneDialogue.png|600]] | ||
| + | # The target to clone the repository to should automatically fill with an appropriate name but you can change this if you wish | ||
| + | # Leave all other fields blank and click "OK" | ||
| + | # The repository should begin to clone to that location | ||
Latest revision as of 10:34, 15 April 2019
Git is a version control system that can be used to track changes to files, allowing you to revert to a specific file version and monitor how the file changes over time. It is most commonly used in source code development but can be used in many other scenarios such as tracking changes to documentation and even binary files. There is a large quantity of information online about the usage of Git, the official Git documentation is a good place to start, but there a numerous other resources as Git is now one of the most commonly used version control systems for software development. As the Git system is largely aimed at usage from the command line, there are many third party graphical user interfaces (as well as an official one) that make usage a little bit easier for beginners, to mention a couple, Tortoise Git and Sourcetree are both good free ones. The focus of this page will be on Tortoise Git.
Overview
Git is intended to be used by either a single developer or a large group of different developers often working in different places. If a repository is accessible to the public, anyone can "clone" it, which means download a complete copy of the repository, including all of the information regarding any changes to it since it was started. This means that even if a version of some software has reached version 10, you can still set your repository to be back in the same state that it was when the software was at version 2, 6, or any other tracked change point.
A few important key things to remember about the workings of Git:
- Each developer has a complete local copy of all files in the repository at all times
- When working in a team, there will be a centrally accessible primary repository that all users upload new changes to, and download other people's changes from
- You can choose when you synchronize you local copy of the files with the primary repository
- When a developer wants to control who changes the contents of the primary repository, they can make it read only so only new changes can be downloaded
A few important pieces of Git terminology and their roles in the workflow:
- The process of downloading new changes from a central repository is called a "pull"
- The process of uploading new changes to a central repository is called a "push"
- Central repositories are known as "remotes"
- When you make changes to your local copy of the repository, these changes are not tracked until you "commit" them.
- Only changes that have been "committed" can be "pushed" or "pulled" to or from a central repository
- Before you "push" or "pull" any changes, your local repository must have no uncommitted changes.
Using Tortoise Git
Tortoise Git is great if you're working in a Windows environment as is integrates with the Shell context menu for explorer. When a folder is controlled by Git, you can either Right-click on or inside a Windows Explorer folder to access the various operations you want to carry out.
Cloning a Repository
To clone a central repository either from an online or local location, the Git->Clone command is used. This creates an exact copy of the repository and automatically references the central repository to your local repository as a "remote" allowing you to "pull" new changes and "push" your changes if you have "write" access to the central repository.
If you are cloning a Git repository from an online location like this Wiki or Github, you will be provided with a "clone URL". This is the online address of the repository.
With Tortoise Git you can use the following steps:
- Navigate to a folder in Windows explorer where you would like the repository to kept
- Right-Click to bring up the context menu
- Choose "Git Clone"
- Enter the repository location in the appropriate field. This is a URL for online locations but can also be a local file system address
- The target to clone the repository to should automatically fill with an appropriate name but you can change this if you wish
- Leave all other fields blank and click "OK"
- The repository should begin to clone to that location
