Explains how to clone a Git repository using the command line, EasyTemplate or with submodules, how to clone a branch in Git, the advantages and an overview of version control. The simple steps show you how to clone from Github easily.
- How to clone a GIT repository to local
- How to clone a Git repository using EasyTemplate
- How to clone a Git repository with submodules
- How to clone a branch in Git
- Version control: an overview
How to clone a GIT repository to local
Cloning your Git repository to your local machine allows you to work and develop your project locally.
Find your SSH key in the SiteGround Git tool
The Git system uses the SSH protocol to transfer data between the server and your local computers. This means that in order to clone the repository you need to have SSH access to your SiteGround hosting account. To see the SSH key, go to your Site Tools > Devs > SSH Keys Manager. Choose the key you have created and go to the Action menu > Private Key:
A new window will appear in which you will be provided with your SSH key:
Due to security reasons, the password for your SSH key will not be displayed in the tool. If you do not know your SSH key password, you will have to generate a new key from Devs > SSH Keys Manager in Site Tools.
Commands to clone locally and commit back online
You can use Linux, Windows, and Mac to clone the repository. This tutorial explains the Linux commands for cloning your Git repository. In this example, the command will clone the repository for the main WordPress site. It is available in your Site Tools > Devs > Git > go to the Action menu for the corresponding repository > Git Info:
git clone ssh://username@server_name:18765/home/customer/www/yourdomain.com/public_html/
Your computer will need several minutes to clone the repository. After that, you should see your application copied on your local computer. If you want to clone your site to a specific folder you can use the following modified command:
git clone ssh://username@server_name:18765/home/customer/www/yourdomain.com/public_html/ /home/user/Desktop/mainsitegit
The above command will clone the repository and the application will be saved on your local computer in the “/home/user/Desktop/mainsitegit” folder. At this stage, the site will be downloaded to your local computer and you can edit your files via your favorite editor. To commit the changes to your local GIT repository you can use the following command:
git commit -a -m "Commit comment."
The above command will commit the changes to your local repository and the comment will be added to the Git logs. To push the changes to the server you have to use the following command:
The system will connect to the server and upload the files that have been modified on your local computer.
How to clone a Git repository using EasyTemplate
If you want to host an exact copy of a git repository on GitHub, for example, this can be done quite easily. First you clone the corresponding repository with the option –mirror and change to the directory. I will simply introduce this using the EasyTemplate as an example. EasyTemplate is a enhancement for Magento CMS Pages which cut ups all elements of your cms-pages in single bricks. Each brick could have several input-elements. Each brick can placed any number of times and in any order – without any html skills!
1 git clone –mirror firstname.lastname@example.org:magento-project/easytemplate.git
2 cd easytemplate.git/
Every git repo always has two URLs stored: fetch and push. It is very easy to find out which ones are current:
1 git remote -v
2 origin email@example.com:magento-project/easytemplate.git (fetch)
3 origin firstname.lastname@example.org:magento-project/easytemplate.git (push)
Ok so far. Now I would like to change the push url – that’s easy with “set url”. The difference here is that we still give -push. Thus only the push url is changed:
1 git remote set-url –push origin email@example.com:webguys-de/EasyTemplate.git
And everything is already configured. In order to carry out a comparison, we now only have to carry out a fetch and a push:
1 git fetch -p origin
2 git push –mirror
The whole thing could of course also be triggered by a shell script, which is triggered, for example, by a hook.
How to clone a Git repository with submodules
A submodule is used to embed a reference to another Git repository in a subdirectory of a Git repository. For example, a project could integrate a library used as a submodule. The commits of the project repository are used to define which version of the embedded submodule repository is to be used:
$ git submodule add <repository> <path> $ git submodule add git: //github.com/jquery/jquery.git libs / jquery /
This enters the submodule with the path and repository URL in the .gitmodules project file :
[submodule "libs/jquery"] path = libs/jquery/ url = git://github.com/jquery/jquery.git
This change must be committed:
$ git status -s A .gitmodules A libs / jquery $ git commit "added submodule"
In addition to the configuration in .gitmodules , a reference to the commit of the embedded repository is now versioned under the submodule path:
$ Git ls-tree master -r 100644 blob 02a7aca40d2bf613c9c79e6c0bfaf2c2c6eecca9 .gitignore 100644 blob 29c99edd93da171b53fbb1f91cb5c730361552fd .gitmodules 100644 blob 9ddb02df2fa3245829f3b644933ef70c28afb2d8 css / style.css 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 html / index.html 160,000 commit 2ac1cd91db5c20cbe8ba0db44f7640cd150060ee libs / jquery <<<<<< <<
If you are in the directory of the submodule, all Git commands refer to the submodule. If the HEAD reference changes here, for example due to a commit or a branch change, this causes a change in the external repository:
$ cd ~ / example / libs / jquery / $ git checkout 2.0.2 $ cd ~ / example / $ git status -s M libs / jquery $ git diff [ ... ] -Subproject commit 2ac1cd91db5c20cbe8ba0db44f7640cd150060ee + Subproject commit b21c88ff0c293db0711d378411901259052ca2b4 $ git add libs / jquery $ git commit
It should be noted that Git does not change the status in the submodule without explicitly specifying this. For example, if you switch to a branch in the external repository that references a different version of the submodule, the submodule repository initially remains unchanged. This is visible with git submodule status :
$ git submodule status -fbb52573d4dcb09d02e7a8c1fd586076dc0d1685 module1 # uninitialized + 9ddb02df2fa3245829f3b644933ef70c28afb2d8 module2 # outdated b1633b39058b6b6b4c0a556448d8536b4e5f6022 module3 # currently
With git submodule update the repository is brought into the appropriate state:
$ git submodule update Submodule path 'module1' : checked out 'fbb52573d4dcb09d02e7a8c1fd586076dc0d1685'
Clone repository with submodules
If you clone a repository with submodules, these are initially ignored by Git and must be explicitly initialized:
$ git submodule update --init Submodule 'libs / jquery' ( git: //github.com/jquery/jquery.git ) registered for path 'libs / jquery' Cloning into 'libs / jquery' ... [ ... ] Submodule path 'libs / jquery ' : checked out ' b21c88ff0c293db0711d378411901259052ca2b4 '
Alternatively, the submodules can be set up directly during cloning:
$ git clone --recursive [url]
How to clone a branch in Git
Git actually allows you to clone only one single branch, for example:
git clone -b mybranch --single-branch git://sub.domain.com/repo.git
If needed to undo, you can also tell Git to pull all branches like this:
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" git fetch origin
Version control: an overview
Git is a distributed version control system. It differs from classic version control systems such as CVS or Subversion in that not only are individual statuses checked out from a central repository, but the entire repository is replicated locally. After a git clone , a complete, full copy of the cloned repository with the entire project history is available locally:
This has a number of advantages:
- Working local – Independently of a central server repository, all features of the version control system can be used locally. The same tools with which the official version of the software is managed in the central repository can now also be used locally to support your own development work.Changes can, for example, be reversed or discarded very quickly. Intermediate statuses can be versioned in the local repository without being immediately visible to other developers in the central repository.This is particularly interesting if you do not have write access to the official repository, e.g. as a helper in an open source project.
- Work offline – You can also work offline – researching the history, switching back and forth between different branches, continuing to work in them and committing changes: all of this is a local operation in Git. When there is an Internet connection again, commits that have occurred locally are transferred to the central repository ( push ) and commits that have taken place there are transferred to the local repository ( pull ). The use of a central repository is even optional: Git can also be used as a purely local tool to save and manage various file statuses and changes to them locally.
- Work on multiple topics separately – Branches can be created very quickly and easily in Git – both in your local repository for managing your own work and in central repositories for coordinating different versions or development lines. Branches can easily be created for every development topic, for every feature and the work on them is no longer mixed up in an “everything-and-every” master branch.This is made possible in particular by the fact that the merging of branches in Git is a simple and uncomplicated operation – if changes affect different places or different files, the changes are automatically merged by Git; if conflicts arise, they can be resolved easily. So it is very easy to switch between different branches and to pound branches together. This also works repeatedly and “back and forth”, since the merging of branches is documented in the history and it is therefore known which changes have already been merged. Many details, such as the automatic detection of renamed files, contribute to the fact that merges work very reliably in practice.This makes it easy to decouple the work on a new feature from one another until the individual topics are really finished and only then to transfer the changes to the central development line. This is particularly useful if a feature is to be published later or if it is to be discarded completely.
- Workflows – Git is very flexible and a wide variety of workflows can be implemented with it. In addition to the use of a classic, central server repository analogous to CVS / SVN, workflows such as “Changes must first be reviewed before they are accepted” through to highly distributed work in which several repositories exist independently of each other can also be done with git deal with.
- Set up repositories in seconds – Another plus point is the excellent git hosting from GitHub and Atlassian / Bitbucket . In a matter of seconds, repositories can be created for open source projects and (partly for a fee) for internal projects and shared with other developers.
- Fast – Since no network access is required to work with the repository, all Git operations are very fast and do not hinder daily work with waiting times. In addition, git is implemented very efficiently – even in larger repositories with thousands of commits, there are seldom waiting times.
- Reliable – Git is extremely reliable: since all content is referenced and cross-checked using SHA1 checksums, it would be noticed immediately if repository content were changed, for example through a bug in the implementation or through manipulation of the repository. Git guarantees that it will reproduce the content as it was given to it for versioning.
Nathan James lives for gaming, and is a fan of everything from vintage Pong to the latest virtual reality games. He also loves to tinker with hardware in that never-ending search for more power and speed.