Куда git скачивает файлы
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Ключ --no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ --oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
Заключение
Мы рассмотрели базовые сценарии работы с системами Git и Github. Каждая приведенная выше команда имеет значительно больше ключей и соответственно возможностей. Постепенное их изучение даст вам возможность легко оберегать свои иходники и больше концентрироваться непосредственно на разработке.
Я только что выполнил следующие команды на моем Ruby на Rails:
где Git на самом деле магазин этот репозиторий? (Это на моем локальном компьютере, но где?)
он создаст ваш репозиторий в .git папка в текущем каталоге.
чтобы быть немного более полным, Git работает с:
- the рабочее дерево (корень которого находится там, где вы сделали git init )
- "путь к репозиторию Git" (где .git , в котором будут храниться ревизии всех ваших файлов)
GIT_DIR - это переменная среды, которая может быть абсолютным или относительным путем к текущему рабочему каталогу.
если не определено, "путь к репозиторию git" по умолчанию находится в корневом каталоге вашего рабочего дерева (опять же, где вы сделали git init ).
вы можете фактически выполнить любую команду Git из любого места с вашего диска, Если вы укажете путь рабочего дерева и путь репозитория Git:
но если вы выполняете их в одном из подкаталогов репозитория Git (без указанного пути GIT-DIR или рабочего дерева), Git просто посмотрит в текущий и родительский каталоги, пока не нашел .git , предположим, что это также корневой каталог вашего рабочего дерева и используйте это .git как единственный контейнер для всех ревизий ваших файлов.
Примечание: .git также скрыт в Windows (msysgit).
Вам придется сделать dir /AH чтобы увидеть его.
git 2.9 (июнь 2016) позволяет настроить это.
обратите внимание, что Git 2.18 (Q2 2018) начинает процесс эволюции, как Git сохраняет объекты путем рефакторинга внутренней глобальной структуры данных, чтобы сделать это возможным чтобы открыть несколько репозиториев, поработайте с ними, а затем закройте их.
вы можете скачать РЕПО как tar.ГЗ так же
как zipball ссылка, указанная различными ответами здесь, есть tarball ссылка, а также которая загружает содержимое репозитория git в .
лучше
Git также предоставляет другой шаблон URL, где вы можете просто добавить тип файла, который вы хотите загрузить на конец url. Этот способ лучше, если вы хотите обработать эти URL-адреса в пакетном или bash-скрипте.
для загрузки определенной фиксации или ветви
заменить master С commit-hash или branch-name в приведенных выше URL-адресах, как показано ниже.
иногда, если кнопка "Загрузить ZIP" недоступна, вы можете нажать на "Raw", и файл должен загрузить в вашу систему.
по состоянию на июнь 2016 года кнопка загрузки ZIP все еще находится на вкладке Code, однако теперь она находится внутри кнопки с двумя вариантами клонирования или загрузки:
Я столкнулся с той же проблемой, но accidentlty я отсортировал эту проблему. 1) войти в github 2) Нажмите на кнопку вилки в правом верхнем углу. 3) после вышеуказанного шага вы можете увидеть клонирование или загрузку в зеленом цвете на вкладке Code.
Если у вас есть учетная запись, войдите в GitHub, после этого вы можете увидеть зеленую кнопку клонировать/загрузить zip-файл. Нажмите эту кнопку, чтобы загрузить код.
кроме того, вы можете загрузить zip-файл, добавив url-адрес РЕПО с "/legacy.zip / master " в конце, чтобы загрузить его в виде zip-файла. Например, url-адрес РЕПО"https://codeload.github.com/facebook/php-webdriver " станет "https://codeload.github.com/facebook/php-webdriver/legacy.zip/master " после добавления.
однако, если у вас нет учетной записи GitHub или вы хотите загрузить определенную ветку, вы можете использовать следующий онлайн-инструмент.
В процессе перехода с SVN на Git мы столкнулись с необходимостью переписывания наших внутренних инструментов, связанных с развёртыванием кода, которые ориентировались на существование линейной истории правок (и разработку в trunk). На Хабре уже публиковались возможные решения этой проблемы через Git-SVN, но мы пошли другим путём. Нам нужна поддержка таких возможностей Git, как branching и merge, поэтому мы решили разобраться в основах, как же работает Git и каким способом должна осуществляться интеграция с ним.
О статье
Материал ориентирован прежде всего на читателей, умеющих работать с Git на уровне обычного пользователя и знающих основные концепции работы с ним. Возможно, статья не будет содержать ничего нового для разработчиков систем контроля версий, поддерживающих легкое создание веток и их надежное слияние. Вся информация взята из открытых источников, в том числе из исходных текстов Git (2d242fb3fc19fc9ba046accdd9210be8b9913f64).
Хранение данных: объекты
В Git единицей хранения данных является объект (англ. object), который однозначно определяется 40-символьным хешем sha1. В объектах Git хранит почти всё: коммиты, содержимое файлов, их иерархию. Сначала объекты представляют из себя обычные файлы в папке .git/objects, а после git gc упаковываются в .pack-файлы, о которых будет рассказано чуть ниже. Для экономии дискового пространства содержимое всех объектов дополнительно сжимается с помощью zlib.
Узнать тип объекта можно, набрав
Также хранение объектов целиком позволяет делать надежное слияние веток с разрешением конфликтов. Но об этом чуть позже.
Tree (иерархия ФС)
объекте типа дерево (англ. tree) хранится список записей, который соответствует иерархии файловой системы. Одна запись представляет из себя следующее:
Права файла в Git могут иметь лишь очень ограниченный набор значений:
040000 — директория;
100644 — обычный файл;
100755 — файл с правами исполнения;
120000 — символическая ссылка.
Тип объекта — это BLOB или tree, для файла и директории соответственно. То есть в объекте типа tree для корневой директории хранится вся иерархия файловой системы, поскольку внутри одного дерева могут быть ссылки на другие деревья.
Commit
В Git один коммит (англ. сommit) представляет из себя ссылку на объект tree, соответствующий корневой директории, и ссылку на родительский коммит (кроме самого первого коммита в репозитории). Также в коммите есть информация об авторе и UNIX timestamp от времени создания.
Если коммит является простым merge ( git merge ), то у него будет 2 родителя: текущий HEAD и коммит, на который указывает . Git также поддерживает стратегию слияния «осьминог» (англ. octopus), при котором он может выполнять merge более двух веток. Для таких коммитов количество родителей будет больше двух.
Pack-файлы
«. It's worth explaining (you are probably aware of it, but
let me go through the basics anyway) how git delta-chains work, and how
they are so different from most other systems.
In other SCM's, a delta-chain is generally fixed. It might be "forwards"
or "backwards", and it might evolve a bit as you work with the repository,
but generally it's a chain of changes to a single file represented as some
kind of single SCM entity. In CVS, it's obviously the *,v file, and a lot
of other systems do rather similar things.
Git also does delta-chains, but it does them a lot more "loosely". There
is no fixed entity. Delta's are generated against any random other version
that git deems to be a good delta candidate (with various fairly
successful heursitics), and there are absolutely no hard grouping rules.
This is generally a very good thing. It's good for various conceptual
reasons (ie git internally never really even needs to care about the whole
revision chain - it doesn't really think in terms of deltas at all), but
it's also great because getting rid of the inflexible delta rules means
that git doesn't have any problems at all with merging two files together,
for example - there simply are no arbitrary *,v "revision files" that have
some hidden meaning.
It also means that the choice of deltas is a much more open-ended
question. If you limit the delta chain to just one file, you really don't
have a lot of choices on what to do about deltas, but in git, it really
can be a totally different issue».
Если кратко, то в pack-файлах объекты группируются по схожести (например, тип и размер), после чего они сохраняются в виде «цепочек». Первый элемент цепочки представляет из себя самую новую версию объекта, а следующий за ним являются диффом к предыдущему. Самые новые версии объекта считаются наиболее запрашиваемыми, поэтому они хранятся выше в цепочке.
Таким образом, Git всё же хранит диффы, но только на уровне непосредственного хранения данных. С точки зрения любого API уровнем выше, Git оперирует объектами целиком, что позволяет реализовывать различные стратегии слияния и легко разрешать конфликты.
Хранение истории
В Git нет отдельного хранилища истории. Всю историю можно развернуть, но лишь пройдя по ссылкам на родителя из нужного вам коммита. Если необходимо просмотреть историю только по одному файлу (или по поддиректории), Git всё равно должен проделать то же самое, но он будет возвращать отфильтрованные результаты. Стоит иметь это ввиду, когда вы делаете интеграцию с Git, и не заставлять Git делать полный просмотр истории на каждый файл.
К тому же, как вы могли заметить, Git не хранит информацию о переименовании файлов. Если нужно понять, переименован файл или нет, Git производит анализ содержимого хранящихся у него объектов и с некоторым (настраиваемым) допуском считает, что файл был переименован.
Merge: трехстороннее слияние (стратегия resolve)
Если нужно выполнить слияние двух веток, то git по умолчанию использует стратегию recursive, но о ней чуть позже. До того, как появилась эта стратегия, использовалась стратегия resolve, которая представляет из себя трехстороннее слияние. Для того, чтобы выполнить такое слияние, нужно иметь 3 версии: общий родитель, версия из одной ветки и версия из другой ветки. Если вы выполняете слияние файлов, то такое трехсторонее слияние может выполняться утилитой diff3, которая входит в стандартный пакет diffutils. Эта скромная и редко упоминаемая утилита, так или иначе, делает всю «грязную работу» по слиянию в большинстве существующих систем контроля версий, включая RCS, CVS, SVN и, конечно же, Git.
Помимо использования аналога diff3 (конкретная реализация, используемая в Git — это LibXDiff), Git также «на лету» вычисляет переименования файлов и использует эту информацию для слияния tree-объектов. Слияние иерархий директорий не представляет из себя ничего принципиально сложного по сравнению с тем, чтобы выполнить слияние файлов, но порождает очень много различных видов конфликтов.
Небольшая иллюстрация того, как Git выполняет трехстороннее слияние в простом случае (взято из man git-merge):
Предположим, у нас есть такая история и текущая ветка — master:
Тем не менее разработка в ветках topic и master может быть продолжена, и тогда слияние уже не будет выглядеть так просто: у нас может быть больше, чем один коммит, который подходит под определение «общий предок»:
Если мы будем использовать стратегию resolve, то будет выбран самый старый общий предок (коммит E). Если в результате выполнения merge были конфликты, разрешённые в коммите H, нам всё равно нужно будет разрешать их ещё раз.
Для выполнения слияния с помощью стратегии resolve Git возьмет коммит E в качестве общего предка и коммиты M и P в качестве двух новых версий. Если в коммите C был конфликт, то конфликтующие изменения можно откатить с помощью git revert (например, это проделано в коммите K), тогда конечное состояние M уже не будет содержать в себе конфликта, и при слиянии конфликтов тоже не будет.
Merge made by the 'recursive' strategy
Представим себе такую историю:
- cоставляем список всех общих предков, начиная с самого свежего;
- берем за текущий коммит самого первого предка;
- выполняем слияние текущего коммита со следующим предком и получаем виртуальный коммит, который берем за текущий;
- выполняем предыдущую операцию до тех пор, пока не закончится список общих предков.
Результатом выполнения этой операции будет виртуальный коммит, который представляет из себя «смерженное» состояние всех общих предков в правильном порядке — разрешение конфликтов тоже попадет в этот коммит, причем более свежие коммиты будут иметь приоритет. Когда мы получили общего предка, выполняется трехсторонее слияние, описанное выше.
Выдержка из merge-recursive.c:
Низкоуровневые команды Git
Если вы работали какое-то время с Git, то вы наверняка знаете о командах checkout, branch, pull, push, rebase, commit и некоторых других. Но изначально Git создавался не как полноценная система контроля версий, а как фреймворк для её создания. Поэтому в Git есть очень богатый набор встроенных команд, которые работают на низком уровне. Приведем некоторые из них, весьма полезные, на наш взгляд:
git rev-parseЭта команда является очень простой: она возвращает хеш коммита для указанной ревизии. Например, git rev-parse HEAD вернет хеш коммита, на который указывает HEAD.
git rev-list .
Команда выводит список хешей коммитов по указанному запросу и может использоваться как более быстрая альтернатива git log . Например, git rev-list branch ^origin/branch ^origin/master выведет все коммиты из ветки branch, которые ещё не были запушены (при условии, что origin/branch и origin/master являются свежими, например перед этим был сделан git fetch ).
Подводные камни: Что касается запросов вида branch ^other_branch, Git может неправильно вывести результаты, если у коммитов стоит неправильное время. Например, в выводе могут быть пропущены коммиты, которые «произошли в будущем» по сравнению с merge ветки.
git diff-index
Показывает разницу между рабочей копией и индексом (.git/index). В индексе Git хранит кеш lstat() от всех файлов, о которых он знает.
git cat-fileЭта команда уже встречалась в статье, но её всё же стоит упомянуть ещё раз. Она позволяет получить содержимое коммита и любого другого объекта Git.
git ls-treeВыводит содержимое tree-объекта в приемлемом виде.
git ls-remoteВыводит информацию о ветках и тегах (вместе с хешами коммитов) из указанного удаленного репозитория.
GIT_SSH
Если вы писали скрипты, которые делают git pull, то скорее всего сталкивались с тем, что SSH запрашивает подтверждение «аутентичности» удаленного репозитория, причём делает это интерактивно. Решение этой проблемы не столь изящное, потому что GIT_SSH должен быть путем к исполняемому файлу (а не опции SSH):
Заключение
Как можно было увидеть, Git позволяет действительно хорошо и надежно работать с ветками, в том числе корректно обрабатывать ситуации, когда у двух веток есть более одного общего предка. Если только вашей целью не является написание своей системы контроля версий, мы бы рекомендовали использовать результаты работы Git, а не пытаться воспроизвести его алгоритм слияния.
Надеемся, данный материал оказался интересным для вас и позволил понять, почему Git работает именно так, а не иначе. Полагаем, что статья будет также полезной для разработчиков различных интерфейсов к Git, приводя к более глубокому пониманию того, что же происходит «под капотом».
repository : введите поле хранилища необработанных объектов
- синтаксический анализатор необработанных объектов-это слой, который обеспечит доступ к содержимому необработанных объектов,
в то время как код анализатора объектов более высокого уровня будет анализировать необработанные объекты и отслеживает родительство и другие объектные отношения с помощью ' struct object '.
пока добавьте только нижний уровень в структуру репозитория.
если вы находитесь на английском компьютере Windows, путь хранения по умолчанию Git будет C:\Documents and Settings\< current_user>\ , потому что в Windows локальные настройки Git по умолчанию находятся в C:\Documents and Settings\< current_user>\.git и поэтому Git создает отдельную папку для каждого repo/clone at C:\Documents and Settings\< current_user>\ и есть все каталоги клонированного проекта.
например, если вы установите Symfony 2 с
каталог и файл Symfony будут в
в корневом каталоге проекта есть скрытый .git каталог, содержащий конфигурацию, репозиторий и т. д.
Я на Windows и нашел свое местоположение, щелкнув правой кнопкой мыши программу Git Bash в меню "Пуск" и выбрав "Свойства". На вкладке Ярлык отображается значение" Start in:". Для меня это было %HOMEDRIVE%%HOMEPATH% , поэтому я открыл приглашение CMD и набрал echo %HOMEDRIVE%%HOMEPATH% чтобы увидеть реальное расположение.
В a .каталог Git в корне проекта. В отличие от некоторых других систем управления версиями, в частности CVS, ни в одном из подкаталогов нет дополнительных каталогов.
Я также не смог найти свой репозиторий git. Я использую Windows 8 и создал свой репозиторий (по ошибке) под C:\Program Files (x86)\Git . Я мог видеть папку репозитория в bash, но не в cmd или Проводнике Windows.
затем я вспомнил о функции "виртуального магазина" Windows. Моя папка репозитория была фактически создана под C:\Users\\AppData\Local\VirtualStore\Program Files (x86)\Git\ и там был мой !
обычно он переходит в папку "Документы" в windows : C:\Users\\Documents\GitHub
теперь как я могу найти путь, где установлен Git? Существует значение по умолчанию, которое используется, если пользователь только что щелкнул установщик Git. Но все может быть по-другому. И когда я вижу все программные файлы в git / bin, я действительно не хочу, чтобы это было в моем %PATH% (которые другие инструменты, такие как TortoiseGit, похоже, тоже не требуют). Я не нашел никаких подсказок в реестре.
какой алгоритм я могу использовать для поиска Git, это не полное сканирование файловой системы? (Я уже сказал, что это нужно быть быстрым?)
я использую следующий пакетный файл, чтобы узнать, где установлен Git для Windows:
Я должен быть прямо вперед, чтобы сделать что-то подобное.Сеть. Просто помните, что вы должны явно проверить 32-разрядную ветвь реестра, если вы находитесь на 64-разрядной Windows.
Edit: Git для Windows 2.6.1 теперь дополнительно пишет the CurrentVersion , InstallPath и LibexecPath значения HKEY_LOCAL_MACHINE\Software\GitForWindows ключ.
Если вы находитесь внутри (или если вы можете открыть) свою оболочку Git bash, вы можете использовать pwd -W
Если вы находитесь в Windows 8 и выше, вот шаги, которые вы можете выполнить.
- перейдите на начальный экран и найдите git.exe
- в результате поиска щелкните правой кнопкой мыши значок Git Gui / Git Bash и выберите Открыть местоположение файла
- вы попадете в flder, где будут расположены ярлыки. Щелкните правой кнопкой мыши на ярлыке и выберите Свойства
- расположение файла можно найти в целевом поле
для мне это было . C:\Users\\AppData\Local\Programs\Git\cmd\git-gui - . EXE-файл"
надеюсь, это поможет
вы также можете открыть Git Bash и ввести where git . Он вернет путь, где Git установлен на вашем компьютере.
посмотрите в реестре в разделе: HKEY_CURRENT_USER\Software\Git-Cheetah
git --man-path возвращает вас в [базовый каталог установки git]\mingw64\share\man. мерзавец.exe находится в [base git installation dir]\cmd.
теперь я не то, что CVS, SVN и т. д. чувак. Когда я открываю в браузере он говорит мне, что я сделал что-то неправильно. Спорим, мне нужен хакерский инструмент? Какой клиент?
(Я имею в виду. почему бы просто не предоставить ZIP-файл? Разве мир недостаточно сложен?)
клонировать этот репозиторий через URL-адресом вот так: да, вам нужен клиент, и этот клиент Git. Это позволит вам вносить изменения, вашей собственной ветви, сливаются обратно в синхронизации с другими разработчиками, сохранить свой собственный источник, который вы можете легко держать в курсе, не скачивая все целиком каждый раз и записывать туда свои изменения и т. д. ZIP-файл не позволит вам это сделать.
Он в основном предназначен для людей, которые хотят развивать источник, а чем люди, которые просто хотят получить источник и не вносить изменения.
но так получилось, что вы также можете получить ZIP-файл:
Что происходит, когда владелец репозитория не подготовил zip-файл, и вы просто хотите загрузить его самостоятельно? Есть ответ, и вам не нужно идти, хотя этот ужасный процесс для загрузки программного обеспечения, установки и регистрации ключей и прочего на GitHub и т. д.!
чтобы просто загрузить репозиторий в виде zip-файла: добавьте дополнительный путь "/ zipball/ master / " в конец URL-адреса репозитория и вуаля, он дает вам zip-файл всей партии.
затем он дает вам zip-файл для загрузки.
Обновлено Июль 2016
по состоянию на июля 2016 на скачать ZIP переехал в клонировать или скачать to ультраправых заголовка под код tab:
если вы не видите кнопки:
- убедитесь, что вы выбрали код вкладка из меню навигации справа или
- РЕПО возможно, не подготовлена молния. Добавить /archive/master.zip до конца URL репозитория и для создания zipfile главной ветви:
чтобы получить исходный код главной ветви в zip-файле. Вы можете сделать то же самое с тегами и именами ветвей, заменив master в URL выше с именем ветви или тега.
чтобы загрузить репозиторий в виде zip-файла через curl :
Если ваш репозиторий является частная:
по состоянию на декабрь 2016 года, клонировать или скачать кнопка все еще находится под <> Code tab, однако теперь он находится в крайнем правом углу заголовка:
меня это тоже озадачило. Кнопка "Загрузить" находится в крайнем правом углу, но вам также нужно быть в верхней папке, чтобы загрузить то, что вы видите. Поднимитесь как можно выше к родительской / корневой папке, а затем найдите кнопку загрузки.
хотя это довольно старый вопрос, у меня есть мои 2 цента на акцию.
Читайте также: