How to clone repository from github

Clone an existing Git repo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Visual Studio 2022 | Visual Studio 2019 | Visual Studio 2017 | Visual Studio 2015

This article provides procedures for the following tasks:

For an overview of the Git workflow, see Azure Repos Git tutorial.

Prerequisites for access to Azure Repos

Repos must be enabled in your Azure DevOps project settings. If the Repos hub and associated pages don’t display, see Turn an Azure DevOps service on or off to reenable Repos.

To view code in private projects, you must be a member of an Azure DevOps project with Basic access level or higher. For public projects, everyone can view the code.

If you don’t have a project, create one or sign up for free.

If you aren’t a project member, get added.

To clone or contribute to code for a private project, you must be a member of the Contributors security group or have the corresponding permissions set. For public projects, anyone can clone and contribute code. To learn more, see What is a public project?

For public projects, users granted Stakeholder access have full access to Azure Repos.

Repos must be enabled in your Azure DevOps project settings. If the Repos hub and associated pages don’t display, see Turn an Azure DevOps service on or off to reenable Repos.

To view code, you must be a member of the Azure DevOps project with Basic access or higher. If you aren’t a project member, get added.

To clone or contribute to code, you must be a member of the Contributors security group, or have the corresponding permissions, in the project you want to change.

To view code, you must be a member of an Azure DevOps project with Basic access or higher. If you aren’t a project member, get added.

To clone or contribute to code, you must be a member of the Contributors security group or have the corresponding permissions.

Get the clone URL of an Azure Repos Git repo

Typically, you need to know the clone URL of the remote repo that you want to clone. The clone URL uniquely identifies the remote repo.

When you’re signed into an Azure DevOps project, Visual Studio supports searching for and cloning project repos without needing to know the clone URL.

From your web browser, open the team project for your Azure DevOps organization, and then choose Repos > Files to open the Files view.

In the Files view, choose Clone to launch the Clone Repository popup.

Copy the clone URL from the Clone Repository popup.

With Azure DevOps Services, the format for the project URL is dev.azure.com// . However, the previous format that references the visualstudio.com format is still supported. For more information, see Introducing Azure DevOps, Switch existing organizations to use the new domain name URL.

Get the clone URL of a GitHub repo

Typically, you need to know the clone URL of the remote repo that you want to clone. The clone URL uniquely identifies the remote repo.

When you’re signed into GitHub, Visual Studio supports searching for and cloning GitHub repos without needing to know the clone URL.

Open a browser and navigate to your GitHub account, select the Repositories tab, and choose the repository to clone.

On the GitHub repository page, choose Code to launch the Clone popup. Copy the clone URL from the Clone popup.

Clone an Azure Repos Git repo

By signing in as a member of an Azure DevOps project, you can clone private repos that are accessible to you, and public repos. Visual Studio supports search, clone, and sync operations on repos that are accessible through authentication.

You can clone a public Azure Repos Git repo without signing in as a member of its parent Azure DevOps project. To clone a public Git repo without signing in, see Clone any Git repo and Connect to a project in Azure DevOps.

Visual Studio 2019 version 16.8 and later versions provides a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer, uncheck Tools > Options > Preview Features > New Git user experience from the menu bar. You can use Git features from either interface interchangeably. Below, we provide a side-by-side comparison for cloning an Azure Repos Git repo.

Visual Studio Git

Visual Studio Team Explorer

After you’ve cloned a remote Git repo, Visual Studio detects the local clone and adds it to the list of Local Repositories in the Git menu.

In Team Explorer, open the Connect page by selecting the Connect button. Choose Manage Connections then Connect to Project.

In Connect to a Project, select the repo you want to clone from the list and select Clone.

If you don’t see your repo listed, filter the list to find it. You may need to add an Azure DevOps Server where the repo is hosted. Select the Add Azure DevOps Server link.

Verify the location of the cloned repo on your PC and select Clone.

To clone an Azure Repos Git repo from the command line, see Clone any Git repo.

Clone a GitHub repo

By signing into GitHub or using SSH authentication, you can clone private repos that are accessible to you, and public repos. Visual Studio supports search, clone, and sync operations on repos that are accessible through authentication.

You can clone a public GitHub repo without signing in to GitHub or otherwise authenticating. To clone a public Git repo without signing in, see Clone any Git repo.

Visual Studio 2019 version 16.8 and later versions provide a Git version control experience that supports search, clone, and sync operations on GitHub repos that are accessible through authentication. To clone a GitHub repo using Team Explorer, see Clone any Git repo. The following steps apply to the Git version control experience.

From the Git menu on the menu bar, choose Clone Repository to open the Clone a repository window.

In the Clone a repository window, select GitHub under Browse a repository to open the Open from GitHub window.

In the Open from GitHub window, sign in to GitHub and choose the remote repo you want to clone. You can use the search box to filter the list of remote repos. Verify the local folder path where you want the local clone to be created, and then choose Clone.

After you’ve cloned a remote Git repo, Visual Studio detects the local clone and adds it to the list of Local Repositories in the Git menu.

To clone a GitHub repo using Team Explorer, see Clone any Git repo.

To clone a GitHub repo from the command line, see Clone any Git repo.

You can also clone a GitHub repo from the command line by using the GitHub CLI.

Clone any Git repo

You can clone any Git repo that’s accessible to you by using the clone URL of the repo.

Visual Studio 2019 version 16.8 and later versions provides a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer, uncheck Tools > Options > Preview Features > New Git user experience from the menu bar. You can use Git features from either interface interchangeably. Below, we provide a side-by-side comparison for cloning any Git repo.

Visual Studio Git

Visual Studio Team Explorer

After you’ve cloned a remote Git repo, Visual Studio detects the local clone and adds it to the list of Local Repositories in the Git menu.

In Team Explorer, open the Connect page by selecting the Connect button. Choose Manage Connections then Connect to Project.

Select Clone under Local Git Repositories and enter the URL for your Git repo. Your team or Git hosting provider gives you this URL.

Select a folder where you want your cloned repo, and then choose Clone.

At the command prompt, run the Git clone command with the clone URL of the remote repo. This command will create a local clone repo under the current folder.

The Git clone command also let’s you specify a folder path after the clone URL to create the repo in a specific location. For example:

The Git clone command also let’s you clone just a single branch. This option is useful when only one branch of a large repo is of interest to you.

When you clone a remote repository, Git assigns the alias origin as shorthand for the URL of the remote repo you cloned. Git commands often use that alias.

Open a Visual Studio solution from a cloned repo

Visual Studio 2019 version 16.8 and later versions provides a Git version control experience while maintaining the Team Explorer Git user interface. To use Team Explorer, uncheck Tools > Options > Preview Features > New Git user experience from the menu bar. You can use Git features from either interface interchangeably. Below, we provide a side-by-side comparison for opening a Visual Studio solution from a cloned repo.

Visual Studio Git

Visual Studio Team Explorer

Right-click on a repository in the Team Explorer Connect view and select Open.

In the Home view in Team Explorer, double-click your project solution file in the Solutions area. The solution opens in Solution Explorer.

At the command prompt, run the following command to open a Visual Studio solution from a cloned repo. This command isn’t a Git command.

Clone and use a GitHub repository in Visual Studio Code

Learn the steps to clone a public repository from GitHub to your local computer using Visual Studio Code.

Clone repository

To get started, download the sample project using the following steps:

When prompted for the Repository URL, select clone from GitHub, then press Enter.

If you are asked to sign into GitHub, complete the sign-in process.

Enter azure-samples/js-e2e-express-server in the Repository URL field.

Select (or create) the local directory into which you want to clone the project.

When you receive the notification asking if you want to open the cloned repository, select Open.

Clone your repo with the following git command:

Change your terminal into that new subdirectory:

Then open in Visual Studio Code:

Initialize new repository

If you don’t have a GitHub repository yet, but would like to start your project locally, initialize your folder with git.

Create a branch for changes

Enter a new branch name. The branch name is visible in the status bar.

Select the branch name in the status bar. This opens the command palette.

The status bar is usually found at the bottom of Visual Studio code.

In the command palette, select +Create a new branch.

Enter your new branch name.

Enter a new branch name. The branch name is visible in the status bar.

Create a new branch named MY-BRANCH with the following git command:

Commit changes locally

Once you have made changes on your branch, commit the changes.

Push a local branch to GitHub

On the Visual Studio Code status bar, select the push icon to the right of the branch name.

Select the remote name from the pop-up box. If you have just one remote, you won’t be asked to select the remote name.

Select the Source Control icon from the activity bar.

Select the remote name from the pop-up box. If you have just one remote, you won’t be asked to select the remote name.

View Git output

You can view the Git commands run when you use the Source control extension. This helps debug when a command fails.

Select the Source Control icon from the activity bar.

Select the ellipsis (. ) then select Show Git Output.

Visual Studio Code tools to work with Git and GitHub

Working in Visual Studio Code with a repository uses separate tools.

KyleMit / CloneAllRepos.md

Clone all repos from GitHub

Here’s a play by play of kenorb’s answer to ‘How to clone all repos at once from GitHub?’ with a breakdown for each command for people (like me) new to bash

TL;DR Run the following command, but replace Kylemit your own Github user name

Or in a single line:

Note: You will need to download and alias jq command in order to use the above script.

Normally, we can run multiple commands by separating with a line return. But if we want to cram everything into a single line, we can use the ; delimiter.

We can get a list of all repositories directly from the User Repos API

List public repositories for the specified user.

We’ll construct the url using variable expansion. If the variable is in a string without quotes or with single quotes, it will be automatically expanded like this:

The command line client for fetching web pages is called cURL

Parameters:

By setting silent mode, it ensures that the only returned values are from the html response itself

The response is a JSON array of repository objects that look something like this:

Our next step is to parse the API data that came in as a string of text into something usable. jq is a “filter” command: it takes an input, and produces an output and helps us query json data, but doesn’t come standard, so you have to download it first.

After downloading, make sure it’s available in your shell by adding to your PATH variable (you might have to restart your shell). One way to make jq available as a command from the downloaded file is to alias it like this:

The filter we’re using ( .[]|.clone_url’ ) consists of several parts:

The | operator combines two filters by feeding the output(s) of the one on the left into the input of the one on the right.

All told, it’ll look like this:

Parameters:

Which will now pipe each line into our final command

To clone any repository address, we can run the following command, which will copy the repository into a new subfolder with the repo’s name within in the current folder.

So before you execute the script, cd your way to where you want your repos setup.

You can make things a little easier on the eyes if you break up each of the commands across seperate lines, but still have them all fire in a single execution (this also provides the benefit of being able to copy and paste the entire script in one motion)

Use a backslash \ for line continuation, and use Shift + Enter while in the editor to create a new line without executing the script. Continued lines, either pasted or typed will be indicated with the > symbol

Once the folders have been added locally, in most client side git GUIs you can just drag the repo folders into the editor to add local references to each of those folders to link to them in Source Tree, etc.

rdnvndr / MainGit.md

Основы работы с Git

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Основы работы с удаленным репозиторием

git clone — создание копии (удаленного) репозитория

Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.

Клонирует репозиторий, используя протокол http:

Клонирует репозиторий с той же машины в директорию myrepo:

Клонирует репозиторий, используя безопасный протокол ssh:

У git имеется и собственный протокол:

Импортирует svn репозиторий, используя протокол http:

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забирает изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

Получает изменений из определенного репозитория:

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:

Команда git pull сразу забирает изменения и проводит слияние с активной веткой. Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:

Забирает изменения и метки из определенного репозитория:

Как правило, используется сразу команда git pull.

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправляет свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

Отправляет изменения из ветки master в ветку experimental удаленного репозитория:

В удаленном репозитории origin удаляет ветку experimental:

Отправляет в удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

Отправляет метки в удаленную ветку master репозитория origin:

Изменяет указатель для удаленной ветке master репозитория origin (master будет такой же как и develop):

Добавляет ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

Работа с локальным репозиторием

git init — создание репозитория

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит.

Индексирует измененный файл, либо оповещение о создании нового:

Вносит в индекс все изменения, включая новые файлы:

Из индекса и дерева проекта одновременно файл можно удалить командой git rm.

Удаляет из индекса и дерева проекта отдельные файлы:

Хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

Вносит в индекс все удаленные файлы:

Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset:

Удаляет из индекса конкретный файл:

Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

Команду git status, пожалуй, можно считать самой часто используемой наряду с командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.

git commit — совершение коммита

Коммит — базовое понятие во всех системах контроля версий, поэтому совершаться он должен легко и по возможности быстро. В простейшем случае достаточно после индексации набрать:

Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов. Есть несколько ключей, упрощающих работу с git commit.

Совершает коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено:

Комментирует коммит прямо из командной строки вместо текстового редактора:

Вносит в индекс и создаёт коммит на основе изменений единственного файла:

Пример написания хорошего сообщения коммита:

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

Если команда достигнет точки ветвления, удаления коммита не произойдет.

Для команд слияния или выкачивания последних изменений с удаленного репозитория примеры резета будут приведены в соответствующих разделах.

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяет коммит, помеченный тегом:

Отменяет коммит, используя его хэш:

Для отмены коммита слияния (коммита у которого несколько родителей), необходимо указать хэш и номер одного из родителей коммита:

Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.

git log — разнообразная информация о коммитах в целом

Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.

Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять » — » перед «README»):

или, если версия git не совсем свежая:

Далее приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее):

изменения, касающиеся отдельной папки:

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

Выводит на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):

Лаконичная информация о коммитах, приводятся только автор и комментарий:

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

В принципе, формат вывода можно определить самостоятельно:

git diff — отличия между деревьями проекта, коммитами и т.д.

Показывает изменения, не внесенные в индекс:

Изменения, внесенные в индекс:

Изменения в проекте по сравнению с последним коммитом:

Можно сравнивать «головы» веток:

или активную ветку с какой-либо:

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:

git blame и git annotate — команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:

Можно указать и конкретные строки для отображения:

Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся:

git grep — поиск слов по проекту, состоянию проекта в прошлом

git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно.

Ищет слова tst в проекте:

Подсчитывает число упоминаний tst в проекте:

Ищет в старой версии проекта:

Команда позволяет использовать логическое И и ИЛИ.

Ищет строки, где упоминаются и первое слово, и второе:

Ищет строки, где встречается хотя бы одно из слов:

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.

Просто перечисляет существующие ветки, отметив активную:

Создаёт новую ветку new-branch:

Удаляет ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

Удаляет ветку в любом случае:

Показывывает те ветки, среди предков которых есть определенный коммит:

Показывает коммит ответвления ветки new-name-branch от ветки master:

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

Создаёт ветку, в которую и произойдет переключение:

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Возвращает somefile к состоянию последнего коммита:

Возвращает somefile к состоянию на два коммита назад по ветке:

git merge — слияние веток, разрешение возможных конфликтов

Слияние веток, в отличие от обычной практики централизованных систем, в git происходит практически каждый день. Естественно, что имеется удобный интерфейс к популярной операции.

Пытается объединить текующую ветку и ветку new-feature:

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.

Произошла неудачная попытка слияния:

Смотрим на проблемные места:

Индексируем наши изменения, тем самым снимая метки:

Совершаем коммит слияния:

Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):

Если же коммит слияния был совершен, используем команду:

git rebase — построение ровной линии коммитов

Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.

В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков.

Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

Вариант, в котором явно указывается, что и куда накладывается:

на master накладывается активная в настоящий момент ветка:

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования, разрешения конфликтов, файлы следует внести в индекс командой:

и продолжить наложение следующих коммитов командой:

Альтернативными выходами будут команды пропустить наложение коммита и перейти к следующему:

и отмена работы команды и всех внесенных изменений:

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).

Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

Git позволяет работать одновременно с несколькими ветками одного репозитория. Для добавления ветки в отдельную директорию необходимо выполнить команду:

Для просмотра всех директориев с ветками можно воспользоваться командой:

Директорию с веткой можно перести в другое место с помощью команды:

После окончания работы с веткой в директории, её можно удалить командой:

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

после обычного клонирования репозитория

Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить точное состояние всех подмодулей необходимо запустить:

Для получения состояния последнего коммита всех подмодулей необходимо выполнить следующую команду:

или использовать аргументы по умолчанию команды git pull:

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо зафиксировать изменения:

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:

Для перемещение подмодуля из одного места репозитория в другое место репозитория необходимо выполнить команду:

Для удаления подмодуля из репозитория необходимо удалить описание подмодуля и каталог с файлами подмодуля:

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации.

Ищет разницу текущего состояния проекта и коммита за номером… сами видите, каким:

То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:

Иногда хватает и четырех символов:

Читает лог с коммита по коммит:

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

Помечает определенный коммит:

Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:

Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки.

Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться.

Что привнес «дедушка» нынешнего коммита:

Обозначения можно объединять, чтобы добраться до нужного коммита:

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

Пример содержимого такого файла:

Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.

Серверные команды репозитория

Проверяет сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория:

Переупаковывает локальный репозиторий:

Создание пустого репозитория на сервере

Импорт svn репозитория на Git-сервер

Связка локальной и удаленной ветки

Отправление ветки local в удаленный репозиторий и установка локальной ветки local отслеживаемой с origin/local:

Пометка локальной ветки как отслеживаемой с origin/local:

Создание новой пустой ветки

Создание пустой ветки с именем newbranch:

Использование Git для получения версии

Установка начала новой версии на текущий коммит:

Получение номера версии для последующие коммитов:

Clone a Git repository in Visual Studio

Visual Studio makes it easy to clone a repository right from the IDE. You can work remotely with the Git provider of your choice, such as GitHub or Azure DevOps.

Prerequisites

To follow this article, you’ll need:

Clone a GitHub repo and sign in

Open Visual Studio.

From the Git menu, select Clone Repository.

If you haven’t interacted with the Git menu before, you might see Clone instead of Clone Repository. If so, select Clone.

And, if Git isn’t on the menu bar, go to Tools > Options > Source Control > Plug-in Selection, and then select Git from the Current source control plug-in dropdown list.

In the Clone a repository window, under the Enter a Git repository URL section, add your repo info in the Repository location box.

Next, in the Path section, you can choose to accept the default path to your local source files, or you can browse to a different location.

Then, in the Browse a repository section, select GitHub.

In the Open from GitHub window, you can either verify your GitHub account information or you can add it. To do so, select Sign in from the drop-down menu.

If you’re signing in to GitHub from Visual Studio for the first time, an Authorize Visual Studio notice appears. Choose the options you want, and then select Authorize github.

Next, you’ll see an authorization confirmation window. Enter your password, and then select Confirm password.

After you link your GitHub account with Visual Studio, a Success notification appears.

After you sign in, Visual Studio returns to the Clone a repository dialog, where the Open from GitHub window lists all the repositories that you have access to. Select the one you want, and then select Clone.

If a list of repositories doesn’t appear, enter the location of your repo, and then select Clone.

Next, Visual Studio presents a list of solution(s) in the repository. Choose the solution you would like to load or open the Folder View in Solution Explorer.

You can change the default Folder View to Solution View from the Git menu. Select Settings > Source Control > Git Global Settings > Automatically load the solution when opening a Git repository to do so.

Open an existing local repository

After you’ve cloned a repo or created one, Visual Studio detects the Git repository and adds it to your list of Local Repositories in the Git menu. From there, you can quickly access and switch between your Git repositories.

Browse to and then clone an Azure DevOps repo

Open Visual Studio.

From the Git menu, select Clone Repository.

In the Browse a repository section of the Clone a repository dialog box, select Azure DevOps.

A Connect to a Project dialog box appears. Follow the prompts to sign in to your Azure account, and then browse to Azure DevOps Server that hosts the files you’re looking for.

Next steps

To continue your journey, visit the Create a repo page.