Download git: Git — Downloading Package

zzet.org|Git. Просто Git. Лекция 1. Введение.

9 Feb 2014

В рамках первой лекции мы познакомимся с тем, что такое системы управления версиями (мне хотелось рефлекторно в конце добавить кода, но это не так. Об этом чуть позже). Сначала мы расскажем о происхождении инструментов для контроля версий, узнаем, какие системы управления версиями сейчас популярны и в чем у них основные различия. Безусловно, рассмотрим, почему именно GIT и познакомимся с ним. Разберемся, как начать работу с Git’ом — как установить и запустить Git на вашей машине и наконец, как настроить его так, чтоб можно было приступить к работе. К концу этой лекции вы будете понимать, зачем Git вообще сделан, почему вам стоит им пользоваться, и будете готовы начать с ним работать.

О контроле версий

Что такое контроль версий, и зачем он вам нужен?

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

В последнее время файлы являются конечным результатом для многих профессий, здесь можно назвать, для примера, писательскую деятельность, научные работы и конечно разработку программного обеспечения. Тратится много времени и сил на разработку и поддержку этих файлов и никто не хочет, чтобы пришлось тратить еще больше времени и сил на восстановление данных потерянных в результате каких-либо изменений.

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

В простейшем случае вышеприведенную проблему можно решить хранением нескольких копий файлов, например, один для исправления ошибок в первой версии проекта и второй для новых изменений. Так как изменения обычно не очень большие по сравнению с размером файла, то можно хранить только измененные строки используя утилиту diff и позже объединять их с помощью утилиты patch. Но что если проект состоит из нескольких тысяч файлов и над ним работает сотня человек? Если в этом случае использовать метод с хранением отдельных копий файлов (или даже только изменений) то проект застопорится очень быстро.

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

Если вы графический или веб-дизайнер и хотели бы хранить каждую версию изображения или макета — а этого вам наверняка хочется — то пользоваться системой контроля версий будет очень мудрым решением. СКВ даёт возможность возвращать отдельные файлы к прежнему виду, возвращать к прежнему состоянию весь проект, просматривать происходящие со временем изменения, определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку, и многое другое. Вообще, если, пользуясь СКВ, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.

Локальные системы контроля версий

Как уже говорилось ранее — один из примеров локальной СУВ предельно прост: многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы.

Чтобы решить эту проблему, программисты уже давно разработали локальные СКВ с простой базой данных, в которой хранятся все изменения нужных файлов

Рисунок 1-1. Схема локальной СКВ.

Одной из наиболее популярных СКВ такого типа является RCS (Revision Control System, Система контроля ревизий), которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools.

RCS была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy). Система позволяет хранить версии только одного файла, таким образом управлять несколькими файлами приходится вручную. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ',v'. Например для файла file.txt версии будут храниться в файле file.txt,v. Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами). Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи. Для хранения версий система использует утилиту diff.

Рассмотрим пример сессии с RCS. Когда мы хотим положить файл под контроль RCS мы используем команду ci (от check-in, регистрировать):

Данная команда создает файл file. txt,v и удаляет исходный файл file.txt (если не сказано этого не делать). Также эта команда запрашивает описание для всех хранимых версий. Так как исходный файл был удален системой мы должны запросить его обратно, что бы вносить изменения. Для этого мы используем команду co (от check-out, контролировать):

Эта команда вынимает последнюю версию нашего файла из file.txt,v. Теперь мы можем отредактировать файл file.txt и после того как закончим изменения опять выполнить команду ci для того что бы сохранить новую измененную версию файла:

При выполнении этой команды система запросит у нас описание изменений и затем сохранит новую версию файла.

Хотя RCS соответствует минимальным требованиям к системе контроля версий она имеет следующие основные недостатки, которые также послужили стимулом для создания следующей рассматриваемой системы:

• Работа только с одним файлом, каждый файл должен контролироваться отдельно;
• Неудобный механизм одновременной работы нескольких пользователей с системой, хранилище просто блокируется пока заблокировавший его пользователь не разблокирует его;
• От бекапов вас никто не освобождает, вы рискуете потерять всё.

Централизованные системы контроля версий

Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.

Рисунок 1-2. Схема централизованного контроля версий.

Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте.

Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.

CVS

CVS (Concurrent Versions System, Система совместных версий) пока остается самой широко используемой системой, но быстро теряет свою популярность из-за недостатков которые я рассмотрю ниже. Дик Грун (Dick Grune) разработал CVS в середине 1980-х. Для хранения индивидуальных файлов CVS (также как и RCS) использует файлы в RCS формате, но позволяет управлять группами файлов расположенных в директориях. Также CVS использует клиент-сервер архитектуру в которой вся информация о версиях хранится на сервере. Использование клиент-сервер архитектуры позволяет использовать CVS даже географически распределенным командами пользователей где каждый пользователь имеет свой рабочий директорий с копией проекта.

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

CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.

Рассмотрим небольшой пример сессии с CVS. Прежде всего надо импортировать проект в CVS, это делается с помощью команды import (импортировать):

$ cd some-project
$ cvs import -m "New project" path-in-repository none start

Здесь опция -m позволяет задать описание изменений прямо в командной строке и если ее опустить, то будет вызван текстовый редактор. Далее указывается путь по которому проект будет храниться в репозитории (path-in-repository в нашем случае) и после него две метки: метка разработчика (может пригодится в случае использования CVS для работы над проектами разработанными кем-то другим) и метка проекта.

После того как мы залили наш проект в репозиторий необходимо создать новый директорий в котором будет находится рабочая копия проекта под контролем CVS и загрузить проект с помощью команды checkout (контроль), или сокращенно co:

$ cd some-working-dir
$ cvs checkout path-in-repository

Для команды checkout мы указываем путь к нашему проекту в репозитории который мы указывали выше в команде import.

Теперь мы можем внести в проект изменения и залить их в репозиторий с помощью команды commit (совершить изменения), или сокращенно ci:

$ cvs commit -m "Some changes"

Также как и для команды import мы указываем комментарий к нашим изменениям с помощью опции -m.

Если мы хотим обновить наш рабочий директорий новой версией проекта из репозитория мы используем команду update (обновить), или сокращенно up:

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

• Так как версии хранятся в файлах RCS нет возможности сохранять версии директорий. Стандартный способ обойти это препятствие — это сохранить какой-либо файл (например, README.txt) в директории;
• Перемещение, или переименование файлов не подвержено контролю версий. Стандартный способ сделать это: сначала скопировать файл, удалить старый с помощью команды cvs remove и затем добавить с его новым именем с помощью команды cvs add;

Subversion

Subversion (SVN) был разработан в 2000 году по инициативе фирмы CollabNet. SVN изначально разрабатывался как “лучший CVS” и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру. Из наиболее значительных изменений по сравнению с CVS можно отметить:

• Атомарное внесение изменений (commit). В случае если обработка коммита была прервана не будет внесено никаких изменений.
• Переименование, копирование и перемещение файлов сохраняет всю историю изменений.
• Директории, символические ссылки и мета-данные подвержены контролю версий.
• Эффективное хранение изменений для бинарных файлов.

Рассмотрим примеры команд, хотя надо заметить, что большинство из них практически повторяют команды CVS. Что бы использовать проект с SVN его надо сначала импортировать в репозиторий с помощью команды import (импортировать):

$ cd some-project
$ svn import -m "New project" path-in-repository

В отличие от CVS не нужно указывать метки разработчика и проекта, которые не часто использовались на практике.

Теперь нам нужно создать рабочую копию проекта с помощью команды checkout (контроль), или co:

$ cd some-working-dir
$ svn checkout path-in-repository

После внесения изменений мы используем команду commit (совершить изменения) , или ci для сохранения изменений в репозитории:

$ svn commit -m "Some changes"

И для обновления рабочей копии проекта используется команда update (обновить), или up:

Распределённые системы контроля версий

И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда “умирает” сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.

Рисунок 1-3. Схема распределённой системы контроля версий.

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

Зачем нужны распределенные системы?

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

Почему распределенная система контроля версий может быть интересна кому-то, кто уже использует централизованную систему — такую как Subversion? Любая работа подразумевает принятие решений, и в большинстве случаев необходимо пробовать различные варианты: при работе с системами контроля версий для рассмотрения различных вариантов и работы над большими изменениями служат ветки разработки. И хотя это достаточно естественная концепция, пользоваться ей в Subversion достаточно не просто. Тем более, все усложняется в случае множественных последовательных объединений с одной ветки на другую — в этом случае нужно безошибочно указывать начальные и конечные версии каждого изменения, что бы избежать конфликтов и ошибок. Для распределенных систем контроля версий ветки разработки являются одной из основополагающих концепций — в большинстве случаев каждая копия хранилища версий является веткой разработки. Таким образом, механизм объединения изменений с одной ветки на другую в случае распределенных систем является одним из основных, что позволяет пользователям прикладывать меньше усилий при пользовании системой.

Краткое описание популярных распределенных СУВ

• Git (http://git-scm.com/) — распределенная система контроля версий, разработанная Линусом Торвальдсом. Изначально Git предназначалась для использования в процессе разработки ядра Linux, но позже стала использоваться и во многих других проектах — таких, как, например, X.org и Ruby on Rails, Drupal. На данный момент Git является самой быстрой распределенной системой, использующей самое компактное хранилище ревизий. Но в тоже время для пользователей, переходящих, например, с Subversion интерфейс Git может показаться сложным;
• Mercurial (http://www.selenic.com/mercurial/) — распределенная система, написанная на языке Python с несколькими расширениями на C. Из использующих Mercurial проектов можно назвать, такие, как, Mozilla и MoinMoin.
• Bazaar (http://bazaar-vcs.org/) — система разработка которой поддерживается компанией Canonical — известной своими дистрибутивом Ubuntu и сайтом https://launchpad.net/. Система в основном написана на языке Python и используется такими проектами, как, например, MySQL.
• Codeville (http://codeville.org/) — написанная на Python распределенная система использующая инновационный алгоритм объединения изменений (merge). Система используется, например, при разработке оригинального клиента BitTorrent.
• Darcs (http://darcs.net/) — распределенная система контроля версий написанная на Haskell используемая, например, проектом Buildbot.
• Monotone (http://monotone.ca/) — система написанная на C++ и использующая SQLite как хранилище ревизий.

Краткая история Git

Как и многие замечательные вещи, Git начинался с, в некотором роде, разрушения во имя созидания и жарких споров. Ядро Linux — действительно очень большой открытый проект. Бо́льшую часть существования ядра Linux (1991-2002) изменения к нему распространялись в виде патчей и заархивированных файлов. В 2002 году проект перешёл на проприетарную РСКВ BitKeeper.

В 2005 году отношения между сообществом разработчиков ядра Linux и компанией, разрабатывавшей BitKeeper, испортились, и право бесплатного пользования продуктом было отменено. Это подтолкнуло разработчиков Linux (и в частности Линуса Торвальдса, создателя Linux) разработать собственную систему, основываясь на опыте, полученном за время использования BitKeeper. Основные требования к новой системе были следующими:

• Скорость
• Простота дизайна
• Поддержка нелинейной разработки (тысячи параллельных веток)
• Полная распределённость
• Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)

С момента рождения в 2005 году Git развивался и эволюционировал, становясь проще и удобнее в использовании, сохраняя при этом свои первоначальные качества. Он невероятно быстр, очень эффективен для больших проектов, а также обладает превосходной системой ветвления для нелинейной разработки.

Основы Git

Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СКВ, таких как Subversion или Perforce. В Git’е совсем не такие понятия об информации и работе с ней как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при использовании Git’а.

Слепки вместо патчей

Главное отличие Git’а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени.

Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.

Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных.

Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.

Это важное отличие Git’а от практически всех других систем контроля версий. Из-за него Git вынужден пересмотреть практически все аспекты контроля версий, которые другие системы переняли от своих предшественниц. Git больше похож на небольшую файловую систему с невероятно мощными инструментами, работающими поверх неё, чем на просто СКВ. Позже, коснувшись работы с ветвями в Git’е, мы узнаем, какие преимущества даёт такое понимание данных.

Почти все операции — локальные

Для совершения большинства операций в Git’е необходимы только локальные файлы и ресурсы, т.е. обычно информация с других компьютеров в сети не нужна. Если вы пользовались централизованными системами, где практически на каждую операцию накладывается сетевая задержка, вы, возможно, подумаете, что боги наделили Git неземной силой. Поскольку вся история проекта хранится локально у вас на диске, большинство операций кажутся практически мгновенными.

К примеру, чтобы показать историю проекта, Git’у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репозитория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у СКВ-сервера или качать с него старую версию файла и делать локальное сравнение.

Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а затем отправить их, как только станет доступна сеть. Если вы пришли домой, а VPN-клиент не работает, всё равно можно продолжать работать. Во многих других системах это не возможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.

Git следит за целостностью данных

Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git’а и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит.

Механизм, используемый Git’ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git’е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

24b9da6552252987aa493b52f8696cd6d3b00373

Работая с Git’ом, вы будете встречать эти хеши повсюду, поскольку он их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого.

Чаще всего данные в Git только добавляются

Практически все действия, которые вы совершаете в Git’е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.

Поэтому пользоваться Git’ом — удовольствие, потому что можно экспериментировать, не боясь что-то серьёзно поломать. Подробнее о том, как Git хранит свои данные и как восстановить то, что кажется уже потерянным, мы рассмотрим позже в курсе лекций.

Три состояния

Теперь внимание. Это самое важное, что нужно помнить про Git, если вы хотите, чтобы дальше изучение шло гладко. В Git’е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. “Зафиксированный” значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.

Таким образом, в проектах, использующих Git, есть три части:

• каталог Git’а (Git directory),
• рабочий каталог (working directory),
• область подготовленных файлов (staging area).

Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git’а.

Каталог Git’а — это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git’а, и именно она копируется, когда вы клонируете репозиторий с другого компьютера.

Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git’а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git’а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git’а выглядит примерно так:

• Вы вносите изменения в файлы в своём рабочем каталоге.
• Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
• Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git’а на постоянное хранение.

Если рабочая версия файла совпадает с версией в каталоге Git’а, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым. Поподробнее об этих трёх состояниях и как можно либо воспользоваться этим, либо пропустить стадию подготовки мы рассмотрим на следующей лекции.

Установка Git

Настало время немного ознакомиться с использованием Git’а. Первое, что вам необходимо сделать, — установить его. Есть несколько способов сделать это; два основных — установка из исходников и установка собранного пакета для вашей платформы.

Установка из исходников

Если есть возможность, то, как правило, лучше установить Git из исходных кодов, поскольку так вы получите самую свежую версию. Каждая новая версия Git’а обычно включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии — часто лучший путь, если, конечно, вас не затрудняет установка программ из исходников. К тому же, многие дистрибутивы Linux содержат очень старые пакеты. Поэтому, если только вы не на очень свежем дистрибутиве или используете пакеты из экспериментальной ветки, установка из исходников может быть самым выигрышным решением.

Для установки Git’а вам понадобятся библиотеки, от которых он зависит:

• curl,
• zlib,
• openssl,
• expat,
• libiconv.

Например, если в вашей системе менеджер пакетов — yum (Fedora), или apt-get (Debian, Ubuntu), можно воспользоваться следующими командами, чтобы разрешить все зависимости:

$ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev

Установив все необходимые библиотеки, можно идти дальше и скачать последнюю версию с сайта Git’а:

http://git-scm.com/download

Теперь скомпилируйте и установите:

$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

После этого вы можете скачать Git с помощью самого Git’а, чтобы получить обновления:

$ git clone git://git.kernel.org/pub/scm/git/git.git

Установка в Linux

Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora, можно воспользоваться yum’ом:

Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt-get:

Установка на Mac

Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git’а, который вы можете скачать со страницы на Google Code:

http://code.google.com/p/git-osx-installer

Рисунок 1-7. Инсталлятор Git’а под OS X.

Другой распространённый способ установки Git’а — через MacPorts (http://www.macports.org). Если у вас установлен MacPorts, установите Git так:

$ sudo port install git-core +svn +doc +bash_completion +gitweb

Вам не обязательно устанавливать все дополнения, но, вероятно, вам понадобится +svn, если вы когда-нибудь захотите использовать Git вместе с репозиториями Subversion.

Установка в Windows

Установить Git в Windows очень просто. У проекта msysGit процедура установки — одна из самых простых. Просто скачайте exe-файл инсталлятора со страницы проекта на GitHub’е и запустите его:

http://msysgit.github.com/

После установки у вас будет как консольная версия (включающая SSH-клиент, который пригодится позднее), так и стандартная графическая.

Пожалуйста, используйте Git только из командой оболочки, входящей в состав msysGit, потому что так вы сможете запускать сложные команды, приведённые в примерах в настоящей книге. Командная оболочка Windows использует иной синтаксис, из-за чего примеры в ней могут работать некорректно.

Первоначальная настройка Git

Теперь, когда Git установлен в вашей системе, хотелось бы сделать кое-какие вещи, чтобы настроить среду для работы с Git’ом под себя. Это нужно сделать только один раз — при обновлении версии Git’а настройки сохранятся. Но вы можете поменять их в любой момент, выполнив те же команды снова.

В состав Git’а входит утилита git config, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git’а и его внешний вид. Эти параметры могут быть сохранены в трёх местах:

• Файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл.
• Файл ~/.gitconfig хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global.
• Конфигурационный файл в каталоге Git’а (.git/config) в том репозитории, где вы находитесь в данный момент. Эти параметры действуют только для данного конкретного репозитория. Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig.

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME (C:\Documents and Settings\$USER или C:\Users\$USER для большинства пользователей). Кроме того Git ищет файл /etc/gitconfig, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.

Имя пользователя

Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]

Повторюсь, что, если указана опция --global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если для каких-то отдельных проектов вы хотите указать другое имя или электронную почту, можно выполнить эту же команду без параметра --global в каталоге с нужным проектом.

Выбор редактора

Вы указали своё имя, и теперь можно выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git’е. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно сделать следующее:

$ git config --global core.editor emacs

Утилита сравнения

Другая полезная настройка, которая может понадобиться — встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:

$ git config --global merge.tool vimdiff

Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту.

Проверка настроек

Если вы хотите проверить используемые настройки, можете использовать команду git config --list, чтобы показать все, которые Git найдёт:

$ git config --list
user.name=Scott Chacon
[email protected]
color.status=auto
color.branch=auto
color. interactive=auto
color.diff=auto
...

Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например из /etc/gitconfig и ~/.gitconfig). В этом случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config {ключ}:

$ git config user.name
Scott Chacon

Как получить помощь?

Если вам нужна помощь при использовании Git’а, есть три способа открыть страницу руководства по любой команде Git’а:

$ git help <команда>
$ git <команда> --help
$ man git-<команда>

Например, так можно открыть руководство по команде config:

Эти команды хороши тем, что ими можно пользоваться всегда, даже без подключения к сети. Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах #git и #github IRC-сервера Freenode (irc. freenode.net). Обычно там сотни людей, отлично знающих Git, которые могут помочь.

Итоги

Теперь у вас должно быть общее понимание, что такое Git, и в чём его отличие от тех ЦСКВ, которыми вы, вероятно, пользовались раньше. Также у вас должна быть установлена рабочая версия Git’а с вашими личными настройками. Настало время перейти к изучению основ Git’а.

Tags:

git learning undev coursify

Как Установить GIT на Ubuntu 14.04

GIT

access_time

7 июня, 2017

hourglass_empty

3мин. чтения

Введение

Git — это одна из самых популярных систем контроля версий. Вы можете управлять вашим программным кодом — наблюдая за изменениями, возвращая предыдущие версии вашего кода или создавая новые ответвления для альтернативного кода, которые сможете объединить с основным в дальнейшем. Это руководство поможет вам установить GIT на Ubuntu 14.04.

Что вам понадобится

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

• Доступ к терминалу Ubuntu 14. 04

Шаг 1 — Установка GIT на Ubuntu

Вариант 1 — Установка GIT с помощью Apt

Ubuntu 14.04 уже содержит Git в стандартном хранилище. Вы можете легко установить его используя менеджер пакетов apt. Для начала необходимо обновить его, вписав данную команду:

sudo apt-get update

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

apt-cache policy git

Примерный результат будет таким:

git:
  Installed: (none)
  Candidate: 1:1.9.1-1ubuntu0.3
  Version table:
     1:1.9.1-1ubuntu0.3 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
     1:1.9.1-1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

Здесь показаны 2 версии — 1:1.9.1-1ubuntu0.3 0 и 1:1.9.1-1 0 . “Предложенная версия” показывает версию, которая будет установлена. Для того, чтобы установить GIT на Ubuntu запустите эту команду:

sudo apt-get install git

Запуск этой команды установит git в вашу систему.

Вариант 2 — Как установить GIT из GitHub

Если вам необходима самая последняя версия git, вы можете установить ее из GitHub. Перед установкой git вам необходимы дополнительные пакеты:

sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev

Далее, пройдите по этой ссылке и скачайте нужную вам версию.

В нашем примере мы будем использовать версию v2.12.0, она может быть извлечена с помощью данной команды:

tar -zxf v2.12.0.tar.gz

Однако вместо v2.12.0.tar.gz, вам нужно использовать имя файла, который вы скачали. Войдите в извлеченный каталог:

cd git-2.12.0/

Далее установите git локально, запустив эту команду:

make prefix=/usr/local all
make prefix=/usr/local install

Шаг 2 — Настройка GIT

После успешной установки Git вам необходимо его настроить. Впишите ваше имя пользователя вместо user_name в данной команде:

git config --global user.name "user_name"

Далее впишите ваш адрес электронной почты вместо [email protected].

git config --global user.email "[email protected]"

Шаг 3 — Список базовых GIT команд

Вот список полезных GITкоманд которые помогут вам начать работу.

Для того, чтобы узнать больше git команд используйте:

git --help

Заключение

Закончив данное руководство вы узнали, как установить GIT на Ubuntu 14. 04. Также вы научились базовой настройке Git и его основным командам. Теперь вы можете управлять вашим программным кодом более эффективно, используя ветки, откатывая изменения и отслеживая ваш код.

Советуем ознакомиться с основными GIT командами в данном руководстве.

Шпаргалка по работе с git и github

Вводная информация

Недавно я начал использовать git и github. Эта статья в первую очередь шпаргалка для самого себя, чтобы при необходимости вернуться к ней. Пока тут небольшая часть данных о git, по мере изучения новых команд, статья будет пополняться.

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

Git hub — хостинг для хранения программных файлов, туда мы будем загружать наши файлы

Репозиторий — отдельный набор файлов, который хранится на Github

Коммит —  снимок состояния файлов, точка восстановления

Пуш — отправить коммит в репозиторий на github

Пул — получить файлы с github

Скачать git

https://git-scm.com/download

Git hub 

https://github.com/

Мой аккаунт на git hub

https://github.com/Yurij-Bo

Команды git

Для работы с git можно использовать командную строку, для управления git нужyы команды, ниже некоторые из них

инициализация(создание) git (предварительно перейти в папку где будем инициализировать git при помощи команды cd)

git init

создание пользователя и почты

git config —global user.name ‘Yurij’

git config —global user.email example@mail. ru

получение статуса по файлам

git status

начинаем отслеживать состояние всех файлов в директории

git add -A

создаем commit, т.е контрольную точку

git commit -a -m»first commit»

смотри лог по коммитам

git log

создаем связь с репозиторием на github

git remote add origin https://github.com/Yurij-Bo/learn_js_udemy.git

отправляем коммит в репозиторий

git push -u origin master

получаем копию репозитория

git clone https://github.com/Yurij-Bo/learn_js_udemy.git

получить последнюю версию с github

git pull

Знакомство с Git и GitHub: руководство для начинающих | by Olga Sayfudinova | NOP::Nuances of Programming

Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

…а, может, вам просто захотелось поучаствовать в своем первом open-source проекте?

Тогда эта статья специально для вас!

На самом деле, в Git нет ничего сложного. Если вы быстро читаете и не тратите уйму времени на установку и регистрацию, то начать работать с GitHub вы сможете уже через 10 минут.

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

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте — Стене на GitHub.

Если вы хотите стать настоящим профессионалом в Git и GitHub, то придется еще многому научиться. Однако информации ниже будет вполне достаточно для изучения основ.

Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. Это настоящая Мекка для технарей. Здесь вы можете попрактиковаться в разработке и придумать что-то свое, найти множество open-source проектов, передовых технологий, различных функций и дизайнов.

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

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

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

Если в статье вы видите команду с угловыми скобками: < > , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.

Пример: git add <имя_файла>. Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py.

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

git clone
git status
git add
git commit -m “ “
git push

Затем к ним добавим еще вот эти:

git init
git branch
git merge
git checkout

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

Не лишней будет и вот такая команда:

git help

О ней мы также поговорим ниже.

(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal).

Шаг 1: Регистрация и установка

Зайдите на GitHub и создайте свой аккаунт. В принципе, этим можно и ограничиться. При желании можете установить Git. Но для работы с GitHub это вовсе не обязательно. Однако если вы планируете заниматься проектами на локальном компьютере, то установка вам все-таки нужна. Можете скачать установщик или установить файлы через менеджер пакетов.

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

git config — global user.name “<ваше_имя>”

замените <ваше_имя> на свое имя в кавычках. Можете написать все, что угодно. Если хотите задать имя только для одного репозитория, то удалите из команды слово global.

Теперь напишите свой адрес электронной почты. Проследите, чтобы он совпадал с адресом, указанным при регистрации на GitHub.

git config — global user.email “<адрес_почты@email.com>”

При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.

Теперь вы готовы к работе с Git на локальном компьютере.

Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта.

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

Если у вас есть директория проекта, то просто перейдите в терминал, а в самой директории проекта выполните команду

git init

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

git init

Допустим, в вашем проекте есть папка new_project. Вы можете перейти в нее из окна терминала и добавить локальный репозиторий. Это делается через следующую команду:

cd new_project
git init

В вашем проекте появилась новая скрытая директория с названием. git. Именно здесь Git хранит все, что ему нужно для отслеживания проекта. Теперь вы можете последовательно добавлять файлы в область подготовки:

git add <имя_первого_файла>

или добавьте сразу все файлы через:

git add .

Создать коммит с этими изменениями можно через команду:

git commit -m “<сообщение_коммита>”

Если изменения вас устраивают, напишите:

git push

и отправьте эти изменения в репозиторий. Проверить, есть ли изменения для отправки, можно в любое время по команде:

git status

При внесении изменений следует обновить и сами файлы:

git add <имя_файла>

или

git add — all

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master.

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

Вариант 2. Я вообще ничего не знаю

Этот вариант выбирают совсем новички в разработке. Вполне возможно, у вас уже есть целая папка с файлами проекта для размещения на GitHub, но вы не знаете, с чего начать.

Ну что ж, приступим к делу!

Допустим, вы хотите создать новый репозиторий. Это место, где будет «жить » ваш проект. Если вы не хотите создавать новый репозиторий, то можете склонировать уже существующий. Именно так вы копируете чужой проект или берете нужную вам информацию для работы/учебы. Мы еще к этому вернемся, но чуть позже.

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

Лучше сразу добавлять в репозиторий README-файл с информацией о проекте. Это можно сделать в момент создания репозитория, поставив галочку в соответствующем поле.

• Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
• Придумайте имя репозитория и добавьте короткое описание.
• Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
• Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Новый репозиторийСоздание нового репозитория

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

• Для начала перейдите в ваш репозиторий.
• Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
• В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
• Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
• Нажмите кнопку Commit changes.

Изменение файла на GitHubПодготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request. Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

Подайте мне вот этот проект!

Возможно, вы захотите клонировать свой новый репозиторий для дальнейшей работы с ним на локальном компьютере. Либо у вас уже есть существующий репозиторий, который вы хотели бы клонировать.

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

Клонирование или скачивание репозитория

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки < >.

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd. Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop. Либо напечатайте cd Desktop. Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop, вам потребуется выбрать нужного пользователя через команду cd <пользователь> (замените <пользователь> на нужное вам имя). Затем снова напечатайте ls, чтобы увидеть весь список. И вот теперь, увидев в списке Desktop, смело печатайте cd Desktop. Сейчас уже можно выполнять git clone!

Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd . .

Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.

Совсем не обязательно создавать репозиторий на Рабочем столе. Клонировать можно в любое место на компьютере. Команду git clone можно выполнять и сразу после открытия терминала. Однако, если вы не очень любите копаться в папках на компьютере, то неплохо будет разместить проект на виду, то есть на Рабочем столе…

Если хотите просто покопаться в каком-то проекте, то вместо клонирования можете сделать форк проекта на GitHub. Для этого нажмите кнопку Fork в верхнем правом углу сайта. Так вы добавите копию этого проекта в свои репозитории и сможете вносить туда любые изменения без вреда для оригинала.

Вот, чем мы займемся:

git status
git add
git commit -m “ “
git push

Но ничего сложного здесь нет!

Должно быть, у вас уже есть файлы, которые вы бы хотели разместить в новом репозитории. Отыщите их на компьютере и перетащите в новую папку репозитория на Рабочем столе.

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

Это ваши предлагаемые изменения. Операцию можно повторить с новыми файлами либо с уже существующими, но измененными. По сути, ничего нового в сам проект вы не добавляете. Вы всего лишь загружаете новые файлы и указываете Git на эти изменения.

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать <>. После внесения изменений создается снимок состояния репозитория, для чего используется командаcommit. А через –m добавляется сообщение об этом снимке.

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

Теперь ваши изменения сохранены в указателе локальной копии проекта. Для отправки изменений на удаленный репозиторий выполните команду:

git push

Тем самым вы отправляете изменения напрямую в репозиторий. Если вы работаете на локальном компьютере и хотите, чтобы коммиты отображались в онлайн, то необходимо своевременно отправлять эти изменения на GitHub по команде git push.

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

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

Читайте также:

Шпаргалка по основам Git/GitHub.

Руководство по контролю версий для… | by Vlad Kopenkin

Руководство по контролю версий для начинающих

Если Вы всё еще не знакомы с системой контроля версий и её использование не входит в Ваш рабочий процесс, то сейчас — самое время начать! Это основополагающее руководство поможет Вам начать работу с Git и даст Вам прочный фундамент для дальнейшего развития. Git почти наверняка используется на любом серьёзном проекте и чем раньше Вы научитесь им пользоваться, тем более ценным сотрудником Вы станете для работодателей. Так же, это улучшит Ваш личный опыт, так как Вы без проблем сможете переключаться между несколькими компьютерами, не волнуясь при этом о переносе проекта через флэш накопители… Работа в команде станет гораздо легче. Бывали ли у Вас случаи, когда код становился настолько запутанным, что казалось, будто было бы легче начать проект с нуля? С системой контроля версий Вы сможете просто вернуться к стабильной версии, без всего того что Вы успели воплотить в 4 часа утра.

Git — это одна из систем контроля версий. По существу это значит, что она хранит всю историю изменений проекта. История Вашего проекта и история изменений этого же проекта у Ваших коллег — у всего будет копия. Это полная противоположность SVN, где вся история изменений храниться в одном месте.

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

Git достаточно мудрёный и выучить каждую из его команд не так-то просто, но для начала работы Вам нужно знать всего несколько ключевых понятий. Чем больше Вы будете использовать Git, тем чаще Вы будете сталкиваться с ситуацией, когда начальных знаний окажется недостаточно, но существует большое количество ресурсов, которые придут к Вам на помощь. Так что используйте это руководство как трамплин, не забывая о дальнейшем развитии.

Первым делом мы загрузим Git. Для пользователей Windows я советую установить и Git Bash, который доступен после установки Git. Для пользователей Mac, использование Terminal будет достаточным. После завершения установки приступайте к регистрации аккаунта GitHub. Итак, у Вас есть Git, инструмент командной строки, и GitHub аккаунт, куда Вы будете загружать свои репозитории.

Используя Git Bash или Terminal перейдите в корневую директорию проекта. Если Вы используете Git Bash, то с помощью правого клика можно выбрать “Git Bash Here” и он запустится в рабочей директории.

git init
Эта команда создаст .git репозиторий в Вашем проекте. Репозиторий или “repo” это коллекция всех изменений, которые были совершены на протяжении всего времени после инициализации репозитория. Это первое что нужно сделать для нового проекта.

git config --global user.name "Ваше Имя"
git config --global user.email "ВашаПочта@mail.com"
Эти команды определят информацию, которая будет использоваться при каждом commit(фиксирование изменений). Их стоит выполнить всего один раз при первичной установке Git.

git add имяФайла.расширение
Замените “имяФайла.расширение” на любой файл, изменения которого Вы пытаетесь зафиксировать, например “index.html”. Эта команда добавит файл в “staging area”(участок подготовки). Воспринимайте staging area, как секцию в которой файлы проходят подготовку к перемещению в Ваш репозиторий.

git add .
Если Вы хотите добавить всё из директории проекта в staging area, то эта команда сделает всё сама.

git add *.html
Если Вы хотите добавить все файлы с расширением .html в staging area то эта команда отлично подойдет. Расширение можно менять в зависимости от предпочтений.

git status
Покажет что уже было добавлено в staging area и какие файлы были изменены и ждут перемещения в staging area.

git reset имяФайла.расширение
Убирает выбранный файл из staging area.

git rm --cached имяФайла.расширение
Убирает файл из staging area и определяет его как игнорируемый.

git commit -m "Описание коммита"
Берёт файлы из staging area и “фиксирует” их в Ваш локальный репозиторий. В кавычки следует вставить краткое описание изменений для конкретного коммита. Постарайтесь описать коммит краткими деталями, например: “устранил проблему при изменении имени пользователя” вместо подобных сообщений “какие-то изменения”

touch .gitignore
Эта команда создаст файл с названием .gitignore. Вы можете открыть этот файл в текстовом редакторе и прописать названия файлов или директорий, изменения в которых Вы не хотели бы отслеживать (они будут игнорироваться Git). Изменения в игнорируемых файлах не будут отображаться при выполнении git status.

git branch названиеВетки
Создает сущность, называемую branch(ветвь). Ветвь — это точная копия Ваших файлов.

git checkout “названиеВетки”
Позволит Вам переключить контроль над созданной Вами веткой и работать в её пределах. Здесь Вы можете совершать любые изменения кода. Когда Вы будете готовы можно совершить commit изменений и отправить изменения в GitHub (об этом ниже) или же можно удалить ветвь, если что-то пошло не так или Вам больше не нужны изменения сделанные в этой ветке.

git merge названиеВетки
Находясь в Master(главной) ветви, Вы можете использовать эту команду, чтобы взять коммиты из любой из ветвей и соединить их вместе.

git remote add origin https://github.com/имяПользователя/проект.git
Эта команда определит “местоположение” Вашего удалённого репозитория. Всё что было до этого происходило исключительно в локальном репозитории на Вашем компьютере. Вам нужно будет перейти в GitHub аккаунт и создать новый удалённый репозиторий, куда Вы сможете отправлять изменения из локального репозитория. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.

git remote
Выведет список из всех удалённых репозиториев, которые были добавлены к Вашему проекту.

git push -u origin master
Эта команда отправит локальные изменения в удалённый репозиторий. Таким образом эту команду стоит прописывать только первый раз.

git push
This is what you will use to push your code to GitHub after your initial push.

git clone https://github.com/имяПользователя/проект.git
Если у Вас отсутствует проект на личном или рабочем компьютере, то эта команда поможет клонировать/загрузить весь проект в текущую директорию.

git pull
Если Вы работаете над одним и тем же проектом с несколькими людьми, то эта команда позволит загрузить последнюю версию из удалённого репозитория и обновить вашу локальную версию.

Надеюсь это руководство поможет Вам начать и понимать что вообще происходит. Буду рад помочь с уточнениями и ответами на вопросы в комментариях.

Оригинал статьи — ссылка

Как установить Git на Debian 10 – База знаний Timeweb Community

Введение

Система контроля версий (например, Git) позволяет регистрировать изменения в файлах, с которыми работают разработчики, дизайнеры и другие IT-специалисты. Такой инструмент дает возможность не только отслеживать сами изменения, но и возвращаться к определенным стадиям разработки, а также создавать отдельные ветки для других путей разработки.

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

Из этой статьи вы узнаете, как установить Git на сервер с ОС Debian 10. Ниже будет представлено два варианта, как это можно сделать, вы можете выбрать любой из них исходя из своих требований.

Требования

Для того, чтобы выполнить дальнейшие действия, у вас должен быть сервер, где установлена ОС Debian 10, и пользователь, которые может выполнять команды sudo.

1 способ: установка Git из стандартных репозиториев

Это самый быстрый способ установить Git, т.к. все необходимое уже есть в стандартных репозиториях Debian. Но есть один важный момент — версия, доступная в репозитории, может быть не самой новой из существующих на данный момент. То есть если вам нужна самая свежая версия Git, воспользуйтесь вторым способом установки ниже.

А тем, кто хочет установить Git из репозиториев Debian, сначала нужно обновить локальный индекс пакетов:

$ sudo apt update

После того, как обновление будет выполнено, введите команду установки Git:

$ sudo apt install git

Традиционно после окончания установки можно проверить, что система контроля версий установилась корректно. Например, можно посмотреть ее версию:

$ git --version

Вывод:

git version 2.20.1

После этого можно переходить к разделу «Настройка Git» ниже.

2 способ: установка Git из исходников

Существует мнение, что установка Git из исходников предпочтительнее установки из стандартных репозиториев, так как в этом случае у вас будет установлена последняя, самая новая версия Git.

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

$ sudo apt update

$ sudo apt install make libssl-dev libghc-zlib-dev libcurl4-gnutls-dev libexpat1-dev gettext unzip

После установки необходимых зависимостей вам нужно выбрать версию, которую вы хотите установить. Для этого перейдите по ссылке https://github.com/git/git

Проверьте, что находитесь в основной ветке (Branch: master). Нажмите на эту кнопку, выберите вкладку “Tags”, а затем версию, которую вы хотите установить. Пометка “rc” означает “release candidate”; такие ветки создаются накануне релиза, однако устанавливать их не рекомендуется, т.к. они могут работать нестабильно.

Теперь вам нужно нажать на зеленую кнопку “Clone or download” и скопировать ссылку на кнопке “Download ZIP” (правая кнопка мыши -> «Копировать адрес ссылки»). Ссылка должна заканчиваться на .zip. 

Теперь вернитесь на свой сервер и перейдите в директорию tmp, куда вы сейчас загрузите временные файлы:

$ cd /tmp

Для загрузки используйте команду wget вместе с ссылкой, которую вы скопировали. Также можно использовать ключ -O для того, чтобы дать файлу определенное название:

$ wget https://github.com/git/git/archive/v2.23.0.zip -O git.zip

Следующим шагом распакуйте архив:

$ unzip git.zip

И перейдите в директорию:

$ cd git-*

Теперь можно создать и установить пакет:

$ make prefix=/usr/local all

$ sudo make prefix=/usr/local install

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

$ git --version

Настройка Git

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

Добавьте информацию со своим именем и электронным адресом:

$ git config --global user.name "имя_пользователя"

$ git config --global user.email "электронный_адрес"

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

$ git config --list

Вывод:

user.name=имя_пользователя

user.email=электронный_адрес

Информация, которую вы ввели, хранится в конфигурационном файле Git, так что вы можете открыть его в любом текстовом редакторе:

$ nano ~/.gitconfig

И изменить информацию в следующем разделе:

[user]

  name = имя_пользователя

  email = электронный_адрес

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

Больше информации про Git вы можете найти в документации на русском языке.

Руководства по Git — установить git · GitHub

Как установить Git на любую ОС

Git можно установить в наиболее распространенных операционных системах, таких как Windows, Mac и Linux. Фактически, Git устанавливается по умолчанию на большинстве компьютеров Mac и Linux!

Проверка Git

Чтобы узнать, установлен ли у вас Git, откройте приложение терминала.

• Если вы работаете на Mac, найдите приложение командной строки под названием «Терминал».
• Если вы работаете на компьютере с Windows, откройте командную строку Windows или «Git Bash».

Открыв приложение терминала, введите git version . Вывод либо сообщит вам, какая версия Git установлена, либо предупредит вас, что git — неизвестная команда. Если это неизвестная команда, читайте дальше и узнайте, как установить Git.

Установите Git с помощью GitHub Desktop

При установке GitHub Desktop также будет установлена ​​последняя версия Git, если у вас ее еще нет. С GitHub Desktop вы получаете версию Git для командной строки с надежным графическим интерфейсом.Независимо от того, установлен ли у вас Git или нет, GitHub Desktop предлагает простой инструмент для совместной работы с Git. Вы можете узнать больше здесь.

Установите Git в Windows

1. Перейдите к последней версии установщика Git для Windows и загрузите последнюю версию.
2. После запуска установщика следуйте инструкциям на экране мастера установки Git Setup до завершения установки.
3. Откройте командную строку Windows (или Git Bash , если вы выбрали не использовать стандартную командную строку Git Windows во время установки Git).
4. Введите git версии , чтобы убедиться, что Git установлен.

Примечание. git-scm — популярный и рекомендуемый ресурс для загрузки Git для Windows. Преимущество загрузки Git из git-scm заключается в том, что загрузка автоматически начинается с последней версии Git, включенной в рекомендуемую командную строку Git Bash . Источником загрузки является тот же установщик Git для Windows, который указан в шагах выше.

Установить Git на Mac

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

Установить Git из установщика

1. Перейдите к последней версии установщика MacOS Git и загрузите последнюю версию.
2. После запуска установщика следуйте инструкциям, пока установка не будет завершена.
3. Откройте командную строку «терминал» и введите git version , чтобы убедиться, что Git установлен.

Примечание. git-scm — популярный и рекомендуемый ресурс для загрузки Git на Mac. Преимущество загрузки Git из git-scm заключается в том, что загрузка автоматически начинается с последней версии Git. Источником загрузки является тот же установщик MacOS Git, указанный в шагах выше.

Установите Git из Homebrew

Homebrew — популярный менеджер пакетов для macOS. Если у вас уже установлен Homwbrew, вы можете выполнить следующие шаги, чтобы установить Git:

1. Откройте окно терминала и установите Git с помощью следующей команды: brew install git .
2. После завершения вывода команды вы можете проверить установку, набрав: git version .

Установить Git в Linux

Интересный факт: Git изначально разрабатывался для версии операционной системы Linux! Таким образом, имеет смысл только то, что его легко настроить для работы в Linux.

Вы можете установить Git в Linux с помощью инструмента управления пакетами, который входит в ваш дистрибутив.

Debian / Ubuntu

1. Пакеты Git доступны с использованием apt .
2. Убедитесь, что у вас установлена ​​последняя версия. Для этого перейдите в оболочку командной строки и выполните следующую команду, чтобы убедиться, что все обновлено: sudo apt-get update .
3. Чтобы установить Git, выполните следующую команду: sudo apt-get install git-all .
4. После завершения вывода команды вы можете проверить установку, набрав: git version .

Fedora

1. Пакеты Git доступны с использованием dnf .
2. Чтобы установить Git, перейдите в оболочку командной строки и выполните следующую команду: sudo dnf install git-all .
3. После завершения вывода команды вы можете проверить установку, набрав: git version .

Примечание. Вы можете загрузить соответствующие версии Git и узнать больше об установке в определенных системах Linux, например об установке Git в Ubuntu или Fedora, в документации по git-scm.

Другие способы установки Git

Хотите установить Git из исходного кода? Узнайте больше здесь.

Напишите свой вклад в эту статью на GitHub.

Начните работу с git и GitHub

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

Зарегистрируйтесь на GitHub
Войти

Как установить Git в Linux, Mac или Windows

Введение в установку Git

Git был разработан и разработан
Линус Торвальдс за разработку ядра Linux. Git обеспечивает поддержку нелинейной распределенной разработки, позволяя нескольким участникам одновременно работать над проектом.Git — самая популярная распределенная система контроля версий и управления исходным кодом.

В этом руководстве объясняется, как установить последнюю, стабильную и предварительно упакованную версию Git в GNU / Linux, Mac OSX и Windows с помощью соответствующих менеджеров пакетов. Git также может быть
скомпилирован из исходников и установлен в любой операционной системе.

Для получения дополнительной информации об использовании и настройке Git см. Наш
Руководство по началу работы с Git.

Примечание

Как установить Git в Mac OSX

Есть разные способы установить Git в Mac OSX.Вы можете установить Git с помощью Homebrew, MacPorts или загрузив пакет установщика Git.

Проверьте, установлен ли уже Git

1. Проверьте, установлен ли Git на вашем Mac, используя:

     git --version
     

   Если Git не установлен на вашем компьютере, терминал выдаст вам следующее сообщение:

2. Нажмите Установить , чтобы установить необходимые инструменты разработчика

   Эти инструменты разработчика, окружающие разработку приложений Xcode и Xcode утилиты доступны от Apple.После того, как вы будете следовать подсказкам и согласитесь с ними, в конце процесса у вас будет рабочая версия Git.

Установите Git с помощью Homebrew в Mac OSX

1. Выполните следующую команду на своем Mac-терминале:

     / bin / bash -c "$ (curl -fsSL https://raw.githubusercontent.com/Homebrew /install/master/install.sh) "
     

2. Когда появится запрос, нажмите клавишу возврата. После завершения установки вы должны увидеть сообщение об успешной установке.

3. Версия Homebrew, которую вы только что установили, может быть не самой последней стабильной сборкой. Поэтому рекомендуется обновлять его. Чтобы обновить Homebrew, введите в терминале следующую команду:

     brew update
     

4. Наконец, чтобы установить Git, выполните:

     brew install git  

Как установить Git в Windows

1. Перейдите на веб-сайт Git
   Страница загрузки.

2. Дважды щелкните последнюю версию Git, чтобы загрузить ее.

3. Когда вы увидите запрос на установку, нажмите Да :

4. Примите условия лицензии GNU:

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

6. Выберите компоненты, которые вы хотите установить. Если вы не уверены, выберите вариант по умолчанию.

7. Выберите редактор по умолчанию для Git:

8. Выберите, как вы хотите использовать Git, из командной строки из представленных параметров:

9. Выберите библиотеку SSL / TLS, которая вы хотите, чтобы Git использовал для HTTP-соединений:

10. Выберите, как Git должен обрабатывать окончания строк в текстовых файлах:

11. Выберите эмулятор терминала, поведение по умолчанию git pull и некоторые дополнительные настройки опции.

    Для простейшей установки оставьте MinTTY для эмулятора терминала, используйте поведение по умолчанию (быстрая перемотка вперед или слияние) и включите кэширование файловой системы при настройке дополнительных параметров. Когда вы закончите выбор параметров конфигурации, нажмите Установить в конце.

12. Нажмите Готово . У вас должна быть работающая установка Git на вашем компьютере с Windows.

Как установить Git в Linux

Действия по установке Git в Linux зависят от того, какой дистрибутив Linux вы используете.В этом разделе показано, как установить Git в Ubuntu, CentOS, Fedora и Arch Linux.

Проверьте, установлен ли Git в Linux

Перед тем, как начать, проверьте, установлен ли Git на вашем компьютере, введя пример команды в терминале. В некоторых дистрибутивах Linux предустановлен Git:

  git --version
  

Если вывод показывает версию Git (см. Пример ниже), у вас уже установлен Git на вашем компьютере с Linux.

  git версия 2.17,1 
 

Если Git не установлен, ваш терминал показывает следующую ошибку:

  -bash: git: команда не найдена 
 

Если ваш терминал подтверждает, что предустановленной версии Git нет, переходите к следующему разделу, который подходит для вашего дистрибутива Linux.

Установка Git в Ubuntu или Debian

Чтобы установить Git, выполните следующую команду:

  sudo apt-get install git
  

Если вы видите ошибку, попробуйте выполнить следующую команду перед установкой Git:

  sudo apt update
  

Установка Git на CentOS

Вариант 1: Установка Git на CentOS с использованием Yum

Чтобы установить Git на CentOS с помощью Yum, выполните следующую команду:

  sudo yum install git
  

Вариант 2: Установка Git на CentOS из исходного кода

1. Чтобы установить Git из исходного кода, сначала установите его зависимости, используя следующие команды:

     sudo yum group install «Инструменты разработки»
   sudo yum install gettext-devel openssl-devel perl-CPAN perl-devel zlib-devel
     

2. Теперь перейдите к
   Страница выпуска Git и выберите версию, которую вы предпочитаете установить.Найдите стабильную версию Git (выберите версию без суффикса -rc ):

3. Найдя нужную версию Git, щелкните по ней. Вы должны увидеть два файла, включенных в выбранную вами версию выпуска (с расширениями .zip и tar.gz ).

4. Щелкните правой кнопкой мыши и скопируйте ссылку на файл с расширением tar.gz . Например, если вы выбрали версию v2.29.1, ваша ссылка для скачивания будет https: // github.com / git / git / archive / v2.29.1.tar.gz .

5. Используйте wget для загрузки выбранной версии Git в CentOS. Замените URL-адрес примера тем, который вы скопировали на предыдущем шаге.

     wget https://github.com/git/git/archive/v2.29.1.tar.gz -O gitdownloadversion.tar.gz
     

   Эта команда загружает v2.29.1.tar.gz как gitdownloadversion.tar.gz .

6. Распакуйте файл, используя tar . Распакуйте его и извлеките файлы с помощью параметра -zxf .Используйте для этого следующую команду:

     tar -zxf gitdownloadversion.tar.gz
     

7. Измените каталог на распакованную папку:

     cd gitdownloadversion- *
     

8. Создайте Makefile в этом каталоге, чтобы помочь скомпилировать загруженные файлы Git:

     make configure
   ./configure --prefix = / usr / local
     

9. После создания файла Makefile скомпилируйте файлы Git, используя:

     sudo make install
     

10. По завершении проверьте версию Git, чтобы убедиться, что установка прошла успешно.

      git --version
      

Установка Git в Fedora

Как и в CentOS, установка Git в Fedora может быть выполнена двумя способами:

  1. Установите Git с помощью Yum

2. Установите Git из исходников.
  

Процесс установки Git из исходных текстов аналогичен установке CentOS выше. Чтобы установить Git с помощью Yum в Fedora, введите следующую команду:

  sudo yum install git-core
  

После успешного выполнения просмотрите версию Git, которая работает, чтобы подтвердить установку:

  git --version
  

Установка Git в Arch Linux

Чтобы установить Git в Arch Linux с помощью pacman, выполните следующую команду:

  sudo pacman -Sy git
  

Установка Git на Gentoo

Вы можете установить Git на Gentoo, используя команду emerge:

  sudo emerge --ask --verbose dev-vcs / git
  

Часто задаваемые вопросы по установке Git

Предустановлен ли Git на Mac?

Нет, Git не предустановлен на Mac.Вы должны его установить.

Как узнать, установлен ли Git?

Чтобы узнать, установлен ли Git в вашей системе, откройте терминал и введите git --version . Если ваш терминал возвращает версию Git в качестве вывода, это подтверждает, что Git установлен в вашей системе.

Являются ли Git и GitHub одинаковыми?

Git и GitHub разные. GitHub размещает репозитории Git в центральном месте, тогда как Git — это инструмент, который управляет несколькими версиями исходного кода на GitHub.

Как загрузить Git для Windows?

Чтобы загрузить Git для Windows, посетите
Страница загрузок на сайте документации Git и выберите самую последнюю версию. Как только вы нажмете на версию, ваша загрузка скоро начнется.

Как проверить версию Git?

Чтобы проверить версию Git, введите git --version и нажмите Enter в терминале. Это покажет вам вашу версию Git в качестве вывода.

Как клонировать репозиторий в Git?

Перейдите на страницу репозитория на GitHub, нажмите зеленую кнопку Code и скопируйте URL-адрес репозитория.Чтобы клонировать репозиторий в вашей системе, откройте Терминал и запустите git clone URL . Замените URL на URL репозитория.

Начало работы с Git

Посетите наше руководство по
Конфигурация Git для полезных команд, которые помогут вам начать работу с репозиториями Git и GitHub.

скачать-git-repo — npm

Загрузите и извлеките репозиторий git (GitHub, GitLab, Bitbucket) с узла.

Установка

  $ npm установить скачать-git-repo
  

API

скачать (репозиторий, пункт назначения, параметры, обратный вызов)

Загрузите репозиторий git в папку назначения с опциями и обратным вызовом .

репозиторий

Сокращенная строка репозитория для загрузки репозитория:

• GitHub — github: владелец / имя или просто владелец / имя
• GitLab — gitlab: владелец / имя
• Bitbucket — bitbucket: владелец / имя

По умолчанию для параметра репозитория используется основная ветвь , но вы можете указать ветвь или тег как фрагмент URL-адреса, например owner / name # my-branch .Помимо указания типа места для загрузки, вы также можете указать настраиваемое происхождение, например gitlab: custom.com: owner / name .
Пользовательское происхождение будет по умолчанию https или git @ для http и клонирования загрузок соответственно, если протокол не указан.
Не стесняйтесь отправлять вопрос или запрос на включение дополнительных опций происхождения.

В дополнение к сокращению для поддерживаемых хостов git, вы также можете напрямую обратиться к репозиторию с помощью:

Это позволит обойти нормализатор сокращений и передать url напрямую.Если вы используете direct без клона, вы должны передать полный URL-адрес в zip-файл, включая пути к ветвям, если это необходимо.
Если вы используете direct с клоном, вы должны передать полный URL-адрес в репозиторий git, и вы можете указать ветку, например, direct: url # my-branch .

направление

Путь к файлу для загрузки репозитория.

вариантов

Необязательный параметр объекта options с параметрами загрузки. Варианты включают:

• clone - логическое значение по умолчанию false - Если true, используйте git clone вместо загрузки http.Хотя это может быть немного медленнее, оно позволяет использовать частные репозитории, если настроены соответствующие ключи SSH.
• Все остальные параметры ( прокси , заголовки , фильтр и т. Д.) Будут переданы соответствующим образом и могут переопределить значения по умолчанию.

обратный звонок

Функция обратного вызова как функция (ошибка) .

Примеры

стенография

Используя http-загрузку из репозитория Github на master.

 
 загрузить ('flippidippi / download-git-repo-fixture', 'test / tmp', function (err) {
 
 console.log (err? 'Ошибка': 'Успех') 
 
}) 
 

Использование git clone из репозитория Bitbucket в моей ветке.

 
 загрузка ('bitbucket: flippidippi / download-git-repo-fixture # my-branch', 'test / tmp', {clone: ​​true}, function (err) {
 
 console.log (err? 'Error') : 'Success') 
 
}) 
 

Использование HTTP-загрузки из репозитория GitLab с настраиваемым источником и токеном.

 
 загрузить ('gitlab: mygitlab.com: flippidippi / download-git-repo-fixture # my-branch', 'test / tmp', {headers: {'PRIVATE-TOKEN': '1234'}} function (err ) {
 
 консоль.log (err? 'Ошибка': 'Успех') 
 
}) 
 

Использование git clone из репозитория GitLab с настраиваемым источником и протоколом.
Обратите внимание, что тип репозитория ( github , gitlab и т. Д.) Не требуется при клонировании из настраиваемого источника.

 
 скачать ('https://mygitlab.com:flippidippi/download-git-repo-fixture#my-branch', 'test / tmp', {clone: ​​true}, function (err) {
 
 console.log (ошибка? 'Ошибка': 'Успех') 
 
}) 
 

Прямой

Использование HTTP-загрузки с прямого URL-адреса.

 
 скачать ('direct: https: //gitlab.com/flippidippi/download-git-repo-fixture/repository/archive.zip', 'test / tmp', function (err) {
 
 console.log (err ? 'Ошибка': 'Успех') 
 
}) 
 

Использование git clone с прямого URL-адреса на мастере.

 
 скачать ('direct: https: //gitlab.com/flippidippi/download-git-repo-fixture.git', 'test / tmp', {clone: ​​true}, function (err) {
 
 console.log (ошибка? 'Ошибка': 'Успех') 
 
}) 
 

Использование git clone из прямого URL в моей ветке.

 
 скачать ('direct: https: //gitlab.com/flippidippi/download-git-repo-fixture.git#my-branch', 'test / tmp', {clone: ​​true}, function (err) {
 
 console.log (err? 'Ошибка': 'Успех') 
 
}) 
 

Лицензия

MIT

Загрузить с Git - MediaWiki

Git - это распределенная система контроля версий.
Он позволяет вам загружать самую последнюю версию исходного кода со всеми ветками и выпусками с тегами в вашем распоряжении.

Вам следует скачать с Git, если вы разработчик и хотите отправлять патчи.

Если вы не хотите разрабатывать , а , а только устанавливаете MediaWiki и расширения, то вместо этого загрузите стабильные выпуски tarball.

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

Предварительные требования

У вас должен быть установлен Git, прежде чем вы сможете его использовать. В зависимости от вашей операционной системы есть много разных способов приобрести Git.Следуйте Gerrit / Tutorial # Set up Git или воспользуйтесь своей любимой поисковой системой.

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

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

Скачать

Вы можете загрузить ядро ​​MediaWiki с помощью Git, а также все расширения, установленные в настоящее время в кластере серверов Wikimedia Foundation, и многие другие расширения, размещенные на Gerrit.

Первым шагом является клонирование основного репозитория MediaWiki.Это займет некоторое время.

Скачать для разработки

Последняя разрабатываемая версия MediaWiki отслеживается в ветке master.

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

Затем в окне терминала введите следующую команду для клонирования с вашим ssh <ИМЯ ПОЛЬЗОВАТЕЛЯ> , чтобы вы могли отправить исправления на проверку:

 git clone ssh: // <ИМЯ ПОЛЬЗОВАТЕЛЯ> @ gerrit.wikimedia.org: 29418 / mediawiki / core.git mediawiki
 

Это клонирует весь основной репозиторий MediaWiki, синхронизированный с основной веткой, в подкаталог с именем mediawiki .

Для установки в другой каталог измените это в командной строке (для получения дополнительной информации см. Эти документы).
После клонирования репозитория вы можете переключаться на разные ветки или теги.
Ветвь разработки, master , является передовой версией MediaWiki для разработчиков; Вам не следует использовать мастер-код для производства ни при каких обстоятельствах, так как он не считается стабильным.

Скачать стабильную ветку

Если вы не хотите разрабатывать программные исправления, но хотите анонимно клонировать ветку стабильного выпуска 1.35, используйте вместо этого следующую команду:

 git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_35 mediawiki
 

Если у вас медленное подключение к Интернету и вы хотите уменьшить количество клонируемых ревизий, добавьте --depth = 1 в команду git clone .

Теги MediaWiki (стабильная версия)

В качестве альтернативы, определенные стабильные версии MediaWiki отслеживаются с помощью «тегов».Они аналогичны выпускам tarball.
В настоящее время это 1.35.1 (стабильный), 1.31.12 (LTS) и 1.31.12 (устаревший).

Вы можете увидеть все доступные теги с помощью:

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

Обновление подмодулей Git

В ветвях есть несколько подмодулей Git для часто используемых расширений и скинов (в главной ветке их нет). Чтобы обновить подмодули, запустите:

 cd mediawiki
git обновление подмодуля --init
 

Получить внешние библиотеки

MediaWiki использует Composer для управления внешними библиотеками PHP, все из которых находятся в каталоге vendor / в каталоге MediaWiki.

Чтобы установить эти необходимые библиотеки, у вас есть выбор:

• Загрузите и установите composer PHAR, при необходимости переименуйте файл composer.phar в соответствии с инструкциями для вашей ОС, а затем запустите обновление композитора --no-dev из каталога MediaWiki. Это рекомендуемый подход.
• Или, если вы не хотите использовать Composer или хотите использовать тот же набор библиотек поставщиков, который используется в производственном кластере WMF, вы можете вместо этого создать каталог vendor / внутри основной папки вашего MediaWiki установка:
  • В учетной записи разработчика используйте эту команду: git clone ssh: // <ИМЯ ПОЛЬЗОВАТЕЛЯ> @gerrit.wikimedia.org:29418/mediawiki/vendor.git
  • Для анонимной оплаты используйте эту команду: git clone https://gerrit.wikimedia.org/r/mediawiki/vendor.git
  • Обратите внимание, что если какое-либо из ваших расширений имеет свои собственные требования к Composer, то вы не можете использовать эту опцию .

До MediaWiki 1.25 внешние библиотеки хранились в основном репозитории, и диспетчер пакетов не требовался.

В курсе

Если вы используете конкретную ветку или разрабатываемую версию («основная» ветка) MediaWiki, получить последние изменения относительно легко.Перейдите в каталог клонов MediaWiki и выполните эту команду:

Будут применены все последние изменения для ветки, которую вы используете.

Для новой версии ядра могут потребоваться более новые версии расширений и скинов, поэтому вы должны войти в каждый каталог расширений и скинов и обновить его с помощью команды типа git pull --recurse-submodules .

Вам также необходимо обновить vendor / любыми более новыми версиями необходимых библиотек.
Это часто означает выполнение следующей команды Composer, но для получения дополнительных сведений см. #Fetch external libraries выше:

После обновления кода и необходимых библиотек вы должны запустить обновление MediaWiki .Сценарий командной строки php для обновления таблиц базы данных по мере необходимости:

 обслуживание PHP / update.php
 

Если вы используете MediaWiki-Vagrant, он предлагает одну команду, vagrant git-update , которая выполняет все эти шаги.

Переход на другую версию

Каждая из наших версий отслеживается как ветки или теги. Чтобы переключиться на другую версию (например, с главной ветки на другую ветку или тег), проверьте конкретную ветку или тег, который вы хотите, в каталоге клонов MediaWiki:

 git checkout <название_отрасли>
 

или

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

Использование Git для загрузки расширений MediaWiki

Список расширений в git

Скачать расширение

В следующих командах замените на имя расширения, которое вы хотите загрузить, без пробелов. Для Extension: TitleKey это будет TitleKey. (с учетом регистра!)

Загрузите и клонируйте расширение из Git:

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

 cd / путь / к / расширениям
git clone ssh: // <ИМЯ ПОЛЬЗОВАТЕЛЯ> @gerrit.wikimedia.org:29418/mediawiki/extensions/ 
 

Вместо этого для анонимной проверки стабильной ветки используйте следующие команды:

 cd / путь / к / расширениям
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/  --branch REL1_35
 

Вы можете просмотреть исходный код расширения в приложении Gerrit gitiles и по URL-адресу:

 https://gerrit.wikimedia.org/g/mediawiki/extensions//+/refs/heads/master
 

Скачать все расширения

Если вы предпочитаете иметь всех расширений MediaWiki, которые находятся на gerrit.wikimedia.org зарегистрирован на вашем компьютере, введите следующее:

Чтобы получить основную ветку со своей учетной записью разработчика:

 git clone ssh: // <ИМЯ ПОЛЬЗОВАТЕЛЯ> @ gerrit.wikimedia.org: 29418 / mediawiki / extensions
 

Вместо этого для анонимной проверки стабильной ветки используйте эту команду:

 git clone https://gerrit.wikimedia.org/r/mediawiki/extensions --branch REL1_35
 

После выполнения команды git clone продолжайте следующие команды:

 cd / путь / к / расширениям
git обновление подмодуля --init --recursive
 

В любое время, чтобы обновить все расширения до последних версий этой ветви, введите:

 cd / путь / к / расширениям
git pull
git обновление подмодуля --init --recursive
 

Чтобы перейти в другую ветку, например, после нового выпуска:

 git submodule foreach 'git checkout -b REL1_31 origin / REL1_31 || : '
 

Помните, что вы должны использовать только версии расширений из того же выпуска, что и эта версия MediaWiki и друг друга.

Чтобы отслеживать главную ветку:

 git submodule foreach 'git checkout -b origin / master || : '
 

Обратите внимание, что , вы не должны использовать мастер-код для производства ни при каких обстоятельствах, так как он не считается стабильным.

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

Удалить удлинитель

1. Удалите « require_once… » или « wfLoadExtension (…) » из LocalSettings.php
2. Удалите любую строку, ссылающуюся на расширение в composer.local.json (обычно в разделе «extra → merge-plugin → include»).
3. Удалите каталог расширения в install-dir / extensions /

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

Список скинов в git

MediaWiki 1.24 и более поздних версий не включает скины в загрузку Git.

Выполните ту же процедуру, что и для расширений (описанных в предыдущем разделе), но используйте скинов вместо расширений во всех URL-адресах и путях.

Подробные инструкции по установке доступны на странице каждого скина здесь, на MediaWiki.org, например, см. Skin: Vector # Installation. Инструкции для всех остальных скинов аналогичны.

См. Также

Приложение

Редакция от 14:26, 21 марта 2019 г. изменила стандарт ссылки на gerrit.wikimedia.org:
с:

gerrit.wikimedia.org/r/p/mediawiki

по адресу:

gerrit.wikimedia.org/r/mediawiki

GitEye (рабочий стол Git) Загрузить | CollabNet VersionOne

               Лицензия  -  CollabNet GitEye (32-разрядная версия Windows)  
            Лицензионное соглашение с конечным пользователем CollabNet GitEye


ВАЖНО: ДОСТУПОМ, СКАЧИВАНИЕ ИЛИ ИСПОЛЬЗОВАНИЕ ЭТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С СЕРТИФИЦИРОВАННОЙ ИНТЕГРАЦИЕЙ COLLABNET («ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ») ВЫ, ВАШИ СОТРУДНИКИ, АГЕНТЫ, ПОДРЯДЧИКИ И ЛЮБОЕ ДРУГОЕ ЛИЦО, ОТ имени которого ВЫ ПРИНИМАЕТЕ ЭТИ УСЛОВИЯ
(КОЛЛЕКТИВНО «ВЫ» ИЛИ «ВАШ») ПРИЗНАЕТЕ, ЧТО ВЫ ПРОЧИТАЛИ, ПОНЯЛИ И
СОГЛАШАЕТЕСЬ СОБЛЮДАТЬ УСЛОВИЯ ДАННОГО ЛИЦЕНЗИОННОГО СОГЛАШЕНИЯ С КОНЕЧНЫМ ПОЛЬЗОВАТЕЛЕМ («СОГЛАШЕНИЕ»).1. Предоставление лицензии. В соответствии с условиями настоящего Соглашения и каждого применимого
      Лицензия третьей стороны (как определено ниже в Разделе 2), CollabNet, Inc.
      ("CollabNet") настоящим предоставляет Вам неисключительный, не подлежащий передаче объект
      лицензия только на код:
       а. Загрузите программное обеспечение;
       б. Копировать Программное обеспечение только для внутреннего использования; и
       c. Вносить изменения в Программное обеспечение и распространять его только для внутреннего пользования, если не указано иное.
           изложены в Лицензии третьей стороны.
      Любые права, прямо не предоставленные CollabNet в настоящем Соглашении, сохраняются за
      CollabNet.Эта лицензия будет действовать до тех пор, пока вы не нарушите ее.
      настоящего Лицензионного соглашения.
  2. Сторонние программы. CollabNet может распространять сторонние программы.
      с Программным обеспечением, которое не является частью Программного обеспечения. Это стороннее программное обеспечение
      программы не требуются для запуска Программного обеспечения, предоставляются для удобства
      Вы и подпадаете под действие их собственных лицензионных условий («Сторонние лицензии»).
      Такие условия лицензии либо прилагаются к сторонним программам, либо могут быть
      можно найти в файлах загрузки или исходного кода.Если вы не согласны соблюдать
      применимые условия Сторонней лицензии для сторонних программ,
      то Вам не следует их устанавливать.
  3. Ограничения на использование. За исключением случаев, разрешенных применимой Сторонней лицензией,
      Вы соглашаетесь не: (а) сдавать в аренду, сдавать в аренду, сублицензировать или иным образом передавать или
      распространять Программное обеспечение, (б) удалять или скрывать уведомления о правах собственности CollabNet,
      (c) реконструировать, переводить, декомпилировать или дизассемблировать Программное обеспечение, или
      (d) победить, обойти или попытаться победить или обойти любые технологические
      ограничения, наложенные CollabNet.Вам может быть отказано в использовании Программного обеспечения для
      любое нарушение данного Раздела 3. CollabNet может прекратить действие лицензии на Программное обеспечение
      предусмотренных настоящим Соглашением, сразу после письменного уведомления вас о вашем
      нарушение Соглашения. Если эта лицензия будет прекращена CollabNet для
      по любой причине, после прекращения действия Вы соглашаетесь прекратить любое использование Программного обеспечения и
      удалить Программное обеспечение из всех Ваших внутренних систем.
  4. Право собственности. Вы признаете и соглашаетесь с тем, что Программное обеспечение всегда будет
      собственность CollabNet или ее лицензиаров и что Программное обеспечение защищено
      согласно законам о коммерческой тайне, авторском праве и других законах об интеллектуальной собственности.Ты
      подтверждаете, что вы не приобретаете никаких прав на Программное обеспечение, явных или
      подразумевается, кроме указанных в настоящем Соглашении. Вы соглашаетесь защищать
      Программное обеспечение от несанкционированного воспроизведения, распространения, раскрытия,
      использование или публикация.
  5. Поддержка. Любое использование Программного обеспечения осуществляется на ваш страх и риск, если вы не зарегистрировались.
      для программы поддержки CollabNet. Программы поддержки CollabNet для продуктов CollabNet
      включают покрытие для сертифицированных интеграций CollabNet:
      https: // www.collab.net/support/support-programs/
6. Отказ от гарантий. Вы соглашаетесь принять на себя весь риск и ответственность за использование
      Программного обеспечения. ВЫ ПОНИМАЕТЕ И СОГЛАШАЕТЕСЬ, ЧТО, ЕСЛИ ИНАЧЕ НЕ УКАЗАНО
      ЛИЦЕНЗИЯ ТРЕТЬИХ СТОРОН, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ИЛИ ЛЮБЫЕ ДРУГИЕ ПРЕДМЕТЫ, ПРЕДОСТАВЛЯЕМЫЕ ВАМ ПО УСЛОВИЯМ
      УСЛОВИЯ НАСТОЯЩЕГО СОГЛАШЕНИЯ ПРЕДСТАВЛЯЮТСЯ «КАК ЕСТЬ». ОТСУТСТВИЕ КАКИХ-ЛИБО ГАРАНТИЙ
      ИЛИ ПРИРОДА ДАННЫЕ, ЯВНО, ПОДРАЗУМЕВАЕМЫЕ ИЛИ ЗАКОНОДАТЕЛЬСТВО, ВКЛЮЧАЯ, НО НЕ
      ОГРАНИЧИВАЕТСЯ ПОДРАЗУМЕВАЕМЫМИ ГАРАНТИЯМИ ПРИГОДНОСТИ ИЛИ КОММЕРЧЕСКОЙ ЦЕННОСТИ.НИ В КОЕМ СЛУЧАЕ
      COLLABNET НЕСЕТ ОТВЕТСТВЕННОСТЬ ЗА ЛЮБЫЕ СЛУЧАЙНЫЕ ИЛИ КОСВЕННЫЕ УБЫТКИ ИЛИ ЛЮБЫЕ
      ОТВЕТСТВЕННОСТЬ ПО ДОГОВОРУ ИЛИ ИСПОЛНЕНИЮ НАСТОЯЩЕГО СОГЛАШЕНИЯ. ВАША ДУША
      И ИСКЛЮЧИТЕЛЬНОЕ СРЕДСТВО ЗАЩИТЫ ОТ ЛЮБЫХ СПОРОВ С КОЛЛАБНЕТОМ В СВЯЗИ С
      ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДОЛЖНО ПРЕКРАТИТЬ ВАШЕ ИСПОЛЬЗОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ БЕЗ КАКИХ-ЛИБО ДАЛЬНЕЙШИХ
      ОТВЕТСТВЕННОСТЬ СО СТОРОНЫ КОЛЛАБНЕТА.
  7. Представления. Вы заявляете и гарантируете, что имеете законное право и
      право заключать настоящее Соглашение и выполнять свои обязательства.Вы согласны
      соблюдать все применимые законы и постановления США и
      иностранные органы власти, включая, помимо прочего, законы, касающиеся
      передача технических данных, таких как шифрование, экспортированных из США
      Государства или страны, в которой вы проживаете. Вы соглашаетесь не экспортировать,
      реэкспортировать или импортировать Программное обеспечение или его документацию с нарушением любых таких
      ограничения, законы или постановления или без всех необходимых разрешений.8. Государственное использование. Программное обеспечение и документация к нему были разработаны в частном
      расходы и предоставляются с «ОГРАНИЧЕННЫМИ ПРАВАМИ», и Правительство должно
      не имеют никаких прав или лицензий на Программное обеспечение, кроме указанных в настоящем документе.
  9. Полнота соглашения. В настоящем Соглашении изложено полное понимание между
      стороны в отношении вопросов, изложенных в настоящем документе, и заменяет все
      предыдущие заявления, договоренности или соглашения, письменные или устные,
      явным или подразумеваемым в отношении предмета, включая, но не
      ограничивается любыми более ранними версиями Соглашения, размещенными в любом CollabNet
      интернет сайт.В настоящее Соглашение могут быть внесены изменения только по взаимному письменному соглашению
      стороны. Любое положение настоящего Соглашения, которое может быть разумно истолковано
      как предназначенные сторонами, чтобы пережить прекращение или истечение срока
      настоящее Соглашение остается в силе при любом таком прекращении или истечении срока действия. Это соглашение
      был написан на английском языке, и в случае конфликта или
      несоответствие между англоязычной версией и любым переводом этого
      Согласие, версия на английском языке имеет преимущественную силу.10. Применимое право. Настоящее Соглашение регулируется законодательством штата
      Калифорния. Вы не можете передавать свои права по настоящему Соглашению без предварительного
      письменное согласие CollabNet. CollabNet может передавать свои права по настоящему Соглашению.
      по своему усмотрению без вашего согласия.
 11. Уведомления. Уведомления вам могут быть отправлены по электронной почте. CollabNet может направлять уведомления
      Вы в отношении настоящего Соглашения или Программного обеспечения по электронной почте или путем отображения уведомлений
      или ссылки на уведомления на www.open.collab.net или любой другой сайт-преемник.
           

Глава 6 Установка Git | Удачного Git и GitHub для пользователейR

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

Если есть вероятность, что он уже установлен, проверьте это, возрадуйтесь и пропустите этот шаг.

В противном случае найдите ниже инструкции по установке для вашей операционной системы.

Git уже установлен?

Перейти к оболочке (Приложение А). Введите which git , чтобы запросить путь к исполняемому файлу Git:

  который мерзавец
## / usr / local / bin / git  

и git --version , чтобы увидеть его версию:

  git --version
## git версия 2.30,0  

Если у вас все получится, это здорово! У вас уже есть Git. Устанавливать не нужно! Двигаться дальше.

Если вместо этого вы увидите что-то вроде git: command not found , продолжайте читать.

Пользователи

macOS могут сразу получить предложение установить инструменты разработчика командной строки. Да, согласитесь! Нажмите «Установить» и читайте подробности ниже.

Windows

Вариант 1 ( настоятельно рекомендуется ): установите Git для Windows, также известный как msysgit или «Git Bash», чтобы получить Git в дополнение к некоторым другим полезным инструментам, таким как оболочка Bash.Да, все эти имена совершенно сбивают с толку, но вы можете встретить их в другом месте, и я хочу, чтобы вы были хорошо информированы.

Нам это нравится, потому что Git для Windows оставляет исполняемый файл Git в обычном месте, что поможет вам и другим программам, например RStudio, найди и пользуйся. Это также поддерживает переход к более профессиональному использованию, потому что оболочка «Git Bash» будет полезна, когда вы выходите за пределы R / RStudio.

• ПРИМЕЧАНИЕ: Когда вас спросят о «Настройке среды PATH», обязательно выберите «Git из командной строки, а также из стороннего программного обеспечения».В противном случае мы считаем целесообразным принять значения по умолчанию.
• Обратите внимание, что RStudio для Windows предпочитает, чтобы Git был установлен ниже C: / Program Files , и, похоже, это значение по умолчанию. Это означает, например, что исполняемый файл Git в моей системе Windows находится по адресу C: / Program Files / Git / bin / git.exe . Если у вас нет особых причин для иного, следуйте этому соглашению.

Это также оставляет вам клиент Git, хотя и не очень хороший. Так что ознакомьтесь с клиентами Git, которые мы рекомендуем (глава 8).

FYI, похоже, это эквивалентно тому, что вы загрузили бы отсюда: https://git-scm.com/download/.

Вариант 2 ( рекомендуется ): установите Git для Windows через диспетчер пакетов Chocolatey. Если это что-то значит для вас, Chocolatey похож на apt-get или Homebrew, но для Windows вместо Debian / Ubuntu Linux или macOS. Насколько я могу судить, использование Chocolatey для установки Git для Windows дает тот же результат, что и установка его самостоятельно (вариант 1).

Это, очевидно, требует, чтобы у вас уже был установлен Chocolatey или вы готовы его установить. Это не сложно, и инструкции здесь. Это может быть полезно, если кажется, что в будущем вы будете устанавливать больше программного обеспечения с открытым исходным кодом.

После установки Chocolatey в оболочке (Приложение A) выполните:

  choco установить git.install  

Устанавливает самый последний пакет Git (Install) X.Y.Z Chocolatey. На момент написания это «Git (Install) 2.29.2.2 ”, но этот номер версии со временем будет увеличиваться.

Если вы будете искать пакеты Chocolatey самостоятельно, то на момент написания вы можете увидеть два пакета, устанавливающих Git - «Git (Install) 2.29.2.2» и «Git 2.29.2.2». Я считаю, что «Git (Install) 2.29.2.2» технически более правильный, но я также думаю, что на самом деле не имеет значения, какой из них вы используете. Здесь можно найти довольно запутанное объяснение. Не беспокойтесь о том, выполните ли вы choco install git.install или choco install git .

macOS

Вариант 1 ( настоятельно рекомендуется ): установите инструменты командной строки Xcode ( не все из Xcode ), включая Git.

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

Примите предложение! Щелкните «Установить».

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

Мы случайно нашли этот триггер на основе Git.

Также обратите внимание, что после обновления macOS вам может потребоваться повторить вышеуказанное и / или повторно согласиться с лицензионным соглашением Xcode. Мы видели, что это приводит к исчезновению панели RStudio Git в системе, где она работала ранее. Используйте команды, подобные приведенным выше, чтобы заставить Xcode предложить вам то, что ему нужно, а затем перезапустите RStudio.

Вариант 2 ( рекомендуется ): установите Git отсюда: http://git-scm.com/downloads.

• Это, пожалуй, лучшее будущее.Он обязательно предоставит вам последнюю версию Git со всеми описанными здесь подходами.
• Домашняя страница GitHub для установщика macOS находится здесь: https://github.com/timcharper/git_osx_installer.
  • По этой ссылке вы можете найти дополнительную информацию, если что-то пойдет не так или вы работаете над старой версией macOS.

Option 3 ( рекомендуется ): если вы планируете серьезно заняться научными вычислениями, вам придется устанавливать и обновлять большое количество программного обеспечения.Вам следует проверить Homebrew, «отсутствующий менеджер пакетов для OS X». Помимо прочего, он может установить для вас Git. После того, как вы установили Homebrew, сделайте это в оболочке:

  brew install git  

Linux

Установите Git через диспетчер пакетов вашего дистрибутива.

Ubuntu или Debian Linux:

Fedora или RedHat Linux:

Полный список для различных менеджеров пакетов Linux и Unix:

https://git-scm.com/download/linux

Скачать FFmpeg


Если вы найдете FFmpeg полезным, вы можете внести свой вклад
пожертвовав.


Дополнительные варианты загрузки


Получить пакеты и исполняемые файлы

FFmpeg предоставляет только исходный код. Ниже приведены ссылки, по которым он уже скомпилирован и готов к работе.

Пакеты Linux

Статические сборки Linux


Получить исходники

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

 git clone https: // git.ffmpeg.org/ffmpeg.git ffmpeg 


Не можете получить доступ к Git или хотите ускорить клонирование и уменьшить использование полосы пропускания?


FFmpeg всегда был очень экспериментальным проектом, ориентированным на разработчиков. Это
является ключевым компонентом многих мультимедийных проектов и имеет добавленные новые функции
постоянно.
Снимки веток разработки работают очень хорошо. 99%
время, чтобы люди не боялись их использовать.


Репозитории Git

Поскольку FFmpeg разработан с помощью Git,
доступно несколько репозиториев от разработчиков и групп разработчиков.


Релизы

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

FFmpeg 4.3.1 "4: 3"

4.3.1 была выпущена 11 июля 2020 г.Это последняя стабильная версия FFmpeg.
из ветки выпуска 4.3, которая была вырезана из master 08.06.2020.

Включает следующие версии библиотеки:

libavutil 56. 51.100
libavcodec 58.91.100
libavformat 58. 45.100
libavdevice 58.10.100
libavfilter 7. 85.100
libswscale 5. 7.100
libswresample 3. 7.100
libpostproc 55. 7.100 

FFmpeg 4.2.4 "Ада"

4.2.4 была выпущена 9 июля 2020 г. Это последняя стабильная версия FFmpeg.
из 4.2, которая была вырезана из master 21.07.2019.

Включает следующие версии библиотеки:

libavutil 56.31.100
libavcodec 58. 54.100
libavformat 58.29.100
libavdevice 58. 8.100
libavfilter 7. 57.100
libswscale 5. 5.100
libswresample 3. 5.100
libpostproc 55. 5.100 

FFmpeg 4.1.6 "аль-Хорезми"

4.1.6 была выпущена 5 июля 2020 г. Это последняя стабильная версия FFmpeg.
из 4.1 релизная ветка, вырезанная из master 02.11.2018.

Включает следующие версии библиотеки:

libavutil 56. 22.100
libavcodec 58. 35.100
libavformat 58.20.100
libavdevice 58. 5.100
libavfilter 7. 40.101
libswscale 5. 3.100
libswresample 3. 3.100
libpostproc 55 3.100 

FFmpeg 4.0.6 "Ву"

4.0.6 была выпущена 3 июля 2020 г. Это последняя стабильная версия FFmpeg.
из ветки выпуска 4.0, вырезанной из master 16.04.2018.

Включает следующие версии библиотеки:

libavutil 56. 14.100
libavcodec 58.18.100
libavformat 58.12.100
libavdevice 58. 3.100
libavfilter 7. 16.100
libswscale 5. 1.100
libswresample 3. 1.100
libpostproc 55. 1.100 

FFmpeg 3.4.8 "Кантор"

3.4.8 была выпущена 4 июля 2020 г. Это последняя стабильная версия FFmpeg.
из ветки выпуска 3.4, которая была вырезана из master 11.10.2017.

Включает следующие версии библиотеки:

libavutil 55. 78.100
libavcodec 57.107.100
libavformat 57.83.100
libavdevice 57.10.100
libavfilter 6.107.100
libavresample 3. 7. 0
libswscale 4. 8.100
libswresample 2. 9.100
libpostproc 54. 7.100 

FFmpeg 3.2.15 "Гипатия"

3.2.15 была выпущена 2 июля 2020 г. Это последняя стабильная версия FFmpeg.
из ветки выпуска 3.2, вырезанной из master 26.10.2016.

Включает следующие версии библиотеки:

libavutil 55. 34.100
libavcodec 57. 64.101
libavformat 57. 56.101
libavdevice 57. 1.100
libavfilter 6. 65.100
libavresample 3. 1. 0
libswscale 4. 2.100
libswresample 2. 3.100
libpostproc 54. 1.100 

FFmpeg 2.8.17 "Фейнман"

2.8.17 была выпущена 7 июля 2020 г. Это последняя стабильная версия FFmpeg.
из ветки выпуска 2.8, которая была вырезана из master 05.09.2015.Среди множества других изменений он включает в себя все изменения от
ffmpeg-mt, libav master от 28 августа 2015 г., libav 11 от 28 августа 2015 г.

Включает следующие версии библиотеки:

libavutil 54.31.100
libavcodec 56. 60.100
libavformat 56. 40.101
libavdevice 56. 4.100
libavfilter 5. 40.101
libavresample 2. 1. 0
libswscale 3. 1.101
libswresample 1. 2.101
libpostproc 53 3.100 

Старые версии

Более старые версии доступны в Старом
Страница релизов.

.