Как скачать файл с github

Удаление локального Git-репозитория

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

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

rm -rf .git

Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:

rm -rf .git*

Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah, выполнить которую необходимо с указанием того же каталога. 

Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи! 

Что такое Git и зачем он нужен?

Git — это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок — полезно для дизайнеров.

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.

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

Каждая точка сохранения вашего проекта носит название коммит (commit). У каждого commit-a есть hash (уникальный id) и комментарий. Из таких commit-ов собирается ветка. Ветка — это история изменений. У каждой ветки есть свое название. Репозиторий может содержать в себе несколько веток, которые создаются из других веток или вливаются в них.

Что лучше сделать перед отправкой локальных файлов

Перед отправкой локальных файлов в удаленный репозиторий лучше всего проиндексировать все файлы нашего нового проекта.

После команды мы можем командой увидеть, что не все файлы находятся в индексе.

Чтобы проиндексировать все файлы текущей папки мы вводим команду:

Точка означает текущую папку.

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

Я бы посоветовал делать комментарий не на русском как в примере выше, а на английском. Это будет хорошей привычкой. Т.е. вместо «начало проекта» хорошо бы написать «start project».

Далее командой git status мы проверяем, что всё сделали правильно и видим такой экран:

Перечислю еще несколько полезных команд для работы с Гитом ниже.

Показывает историю коммитов.

Команда выше показывает через хеш коммита какие изменения были произведены.

Изменение старых или нескольких коммитов

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

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

Подробную информацию об интерактивной операции rebase и дополнительных командах перебазирования см. на странице git rebase.

Изменение файлов после коммита

Во время операции rebase команда редактирования (edit, или) остановит процесс на указанном коммите и позволит вам внести дополнительные изменения с помощью команды . Git прервет работу и выведет следующее сообщение:

Несколько комментариев

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

• Опция reword, или r, остановит операцию rebase и позволит переписать отдельный комментарий к коммиту.
• Опция squash, или s, приостановит операцию rebase для любых коммитов, отмеченных символом , и вам будет предложено ввести один общий комментарий вместо нескольких отдельных. Подробнее об этом можно узнать в разделе о склеивании коммитов ниже.
• Опция fixup, или f, позволяет объединить комментарии, как и squash. При этом, в отличие от squash, опция fixup не прерывает операцию rebase с открытием редактора для объединения комментариев к коммитам. В коммитах, отмеченных символом f, комментарии будут сброшены и заменены комментарием предыдущего коммита.

Склеивайте коммиты для поддержания чистой истории

Команда склеивания () позволяет в полной мере понять смысл rebase. Склеивание дает возможность указать коммиты, которые нужно объединить в предыдущие коммиты. Таким образом создается «чистая история». Во время перебазирования Git будет исполнять указанную команду rebase для каждого коммита. В случае склеенных коммитов Git откроет выбранный текстовый редактор и предложит объединить комментарии к указанным коммитам. Этот процесс можно представить следующим образом:

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

Современные решения для хостинга Git (например, Bitbucket) предоставляют возможности «автосклеивания» при слиянии. Это позволяет автоматически выполнять rebase и склеивать коммиты ветки при использовании интерфейса решений для хостинга. Дополнительную информацию см. в разделе «Склеивание коммитов при слиянии ветки Git в Bitbucket».

Команда git rebase позволяет изменять историю, а выполнение интерактивной операции rebase «подчищает» за вами следы. Теперь вы можете совершать и исправлять ошибки, оттачивая свою работу и сохраняя чистую, линейную историю проекта.

Ветвление

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

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

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

Стандартные команды:

•  — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
•  — переключается на эту ветку. Можно передать опцию , чтобы создать новую ветку перед переключением;
•  — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

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

В общем,  связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как  перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды . Чтобы вернуть изменения, используйте .

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

Знакомьтесь, pass

Перевод

Я много лет искал подходящую мне хранилку паролей и недавно наткнулся на Pass на HackerNews. Идея хранить пароли в git-репозитории может выглядеть странно, но в целом это неплохая идея, потому что:

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

Я использую -c чтобы копировать/вставлять пароли. Есть расширение для браузера, но копипейст лично мне удобнее. Проблемы синхронизации с телефоном и всеми linux-дейвайсами тоже не стоит (потому что это всего лишь git).
Делюсь с вами переводом приветственной странички Pass.
Управление паролями должно быть простым и следовать философии Unix. Используя pass, каждый Ваш пароль находится внутри зашифрованного файла gpg, имя которого совпадает с именем ресурса или веб сайта к которому данный пароль привязан. Эти зашифрованные файлы могут быть организованы в удобные иерархии папок, скопированы с носителя на носитель и, в общем, обработаны с помощью любых утилит управления файлами командной строки.
С pass управлять отдельными файлами паролей становится крайне просто. Все пароли хранятся в ~ / .password-store, а pass предоставляет несколько удобных команд для добавления, редактирования, генерации и получения паролей. Это очень короткий и простой Shell скрипт. Он способен временно помещать пароли в буфер обмена и отслеживать изменения паролей с помощью git.

Переносим удалённый репозиторий на ПК

Перейдите на сайт desktop.github.com и скачайте GitHub Desktop — это приложение, которое позволит синхронизировать удалённый репозиторий на GitHub и файлы на вашем компьютере без командной строки терминала:

• Скачиваем приложение под свою операционную систему.
• Открываем приложение и проходим авторизацию — нужно указать электронную почту и данные вашего GitHub-аккаунта.
• Приложение синхронизируется с удалённым репозиторием и предложит выполнить одно из следующих действий: создать новый репозиторий, добавить локальную папку с компьютера в GitHub Desktop или клонировать существующий репозиторий в папку компьютера.

Мы создали тестовый удалённый репозиторий, поэтому выберем третий вариант — клонировать существующий репозиторий в папку компьютера.

После установки GitHub Desktop запросит синхронизацию с GitHub-аккаунтом. Если аккаунта нет, приложение предложит его создать
Рабочее пространство в GitHub Desktop — мы можем клонировать репозиторий, создать новый или перенести нужные файлы с компьютера
Выбираем репозиторий, сохраняем его на рабочем столе и жмём кнопку Clone

После клонирования репозитория в рабочем пространстве появятся три вкладки: Current Repository, Current Branch и Fetch origin.

• Current Repository — раздел позволяет переключаться между несколькими репозиториями, отслеживать невнесённые изменения (вкладка Changes) и смотреть историю коммитов (вкладка History).
• Current Branch — раздел позволяет переключаться между несколькими ветками проекта.
• Fetch origin — раздел обновляет внесённые изменения и синхронизирует файлы локального и удалённого репозитория.

Обратите внимание на раздел Current Repository и вкладку Changes. В левом нижнем углу есть окно для добавления коммитов и комментариев — это означает, что вы можете записывать каждый шаг, не посещая сайт GitHub

Рабочее пространство для работы с клонированным репозиторием
История изменений нашего репозитория

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

Создание проекта

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

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

Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:

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

Отправка изменений

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

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

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

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

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Подключите локальную папку проекта к вашему пустому хранилищу на Github

Сейчас на сайте github вы видите страницу у которой в заголовке написано: «Quick setup — if you’ve done this kind of thing before».

Скопируйте ссылку в поле формы (input) прямо под заголовком, она должна выглядеть примерно так:

Это веб-адрес (ссылка), который будет использовать ваша локальная папка для отправки содержимого в удаленную папку на Github.

1. Вернитесь к своему проекту в терминале / командной строке.

2. В вашем терминале / командной строке введите:

Наш пример:

3. Отправьте (сделайте пуш, push) вашей ветки в Github:

4. Вернитесь к экрану репозитория на Github, который вы только что оставили, и обновите его. Название «Quick setup — if you’ve done this kind of thing before». Название должно исчезнуть, и вы должны увидеть свои файлы в репозитории.

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

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

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

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

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

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

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

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

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

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

Создание Git-репозитория

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

Откройте «Командную строку‎» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.

В Linux выполните команду: ‎

cd /home/user/directory

В macOS

cd /Users/user/directory

В Windows:

cd C:/Users/user/directory

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

git init

Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git. Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:

git add

git commit -m 'initial project version'

Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.

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

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

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

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

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

cd Desktop

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

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

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

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

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

Добавляем файлы в проект

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

git statusgit addgit commit -m “ “git push

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

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

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

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

git status

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

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

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

git add — all

или даже:

git add .

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

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

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

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

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

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

git push

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

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

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

• Как писать Bash-однострочники для клонирования и управления GitHub/GitLab репозиториями
• Top 100 наиболее популярных репозиториев на GitHub
• Основы Git за 5 минут

Клонирование существующего репозитория

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

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

Для клонирования существующего репозитория понадобится ввести git clone <url>. Пример такой команды вы видите ниже:

git clone https://github.com/rep/rep

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

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

git clone https://github.com/rep/rep myrep

Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:

Cloning into 'Git'...

remote: Counting objects: 46, done.

remote: Compressing objects: 100% (25/25), done.

remote: Total 46 (delta 7), reused 43 (delta 4), pack-reused 0

Unpacking objects: 100% (46/46), done.

Checking connectivity... done.

Добавляем удалённый репозиторий

Репозиторий — это файловое хранилище проектов. На бесплатном тарифе можно загружать до 500 МБ данных и создавать неограниченное количество репозиториев.

Чтобы создать репозиторий, нажмите на кнопку New repository, назовите проект и кликните Create repository. Можно добавить описание проекта, сделать его публичным или приватным и прикрепить технические файлы:

• README file содержит подробное описание проекта — так другие разработчики узнают, какой репозиторий они смотрят и зачем он нужен.
• Gitignore позволяет сэкономить место и не заливать на GitHub лишние файлы. Например, можно исключить скрытые файлы Mac OS.
• License добавляет к коду ссылку на первоисточник и защищает права разработчика. Лицензия позволяет понять, как правильно использовать чужой код и можно ли его свободно внедрять в коммерческие проекты.

Мы создаём тестовый репозиторий, поэтому обойдёмся без лицензии — выберем только два дополнительных файла: README file и gitignore. Если вы пока не знаете, что писать в README file и что добавлять в gitignore, — оставьте эти файлы пустыми или посмотрите инструкцию в разделе Read the guide.

Мы создали публичный репозиторий и будем хранить файлы в папке test
Мы создали публичный репозиторий и будем хранить файлы в папке test

• Переходим на сайт gitignore.io.
• Добавляем macOS или другую операционку, с которой вы работаете.
• Жмём Create и получаем нужный служебный файл.
• Копируем данные и переносим их в файл gitignore на GitHub.

После редактирования gitignore делаем коммит — записываем в историю проекта факт того, что мы установили ограничение для файлов Mac OS.

Работа со своим первым репозиорием Git

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

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

1. Вызываем контекстное меню и выбираем пункт “TortoiseGit — Settings“:

В появившемся окне переходим сразу к пункту “Git – Config” и записываем свое имя и адрес электронной почты. Эти данные должны в точности совпадать с теми, что записаны в Вашем аккаунте на github, иначе ваш ключ просто не подойдет.

2. Клонируем репозиторий. Для этого заходим на страницу проекта, и копируем в буфер адрес:

Теперь жмем правой кнопкой мыши на директории, в которой будем хранить исходники и в меню выбираем “Git Clone..“:

В открывшемся окне в поле URL вставляем скопированный адрес и жмем “Ok”:

Начнется процесс клонирования репозитория.

Всё вышесказанное можно было бы заменить всего двумя командами в консоли:

После клонирования репозитория Вы автоматически переключитесь на нашу главную ветку (master). Так как каждый из нас занят определенной работой в проекте, то у каждого своя ветвь в репозитории, поэтому и Вам придется создавать свой branch. Делается это достаточно просто.

3. Создаем свою ветку. Для этого жмем правую кнопку мыши на директории в которую мы клонировали репозиторий и выбираем в меню “TortoiseGit — Create Branch“:

В открывшемся оке задаем название новой ветки и указываем на основании какой ветки репозитория мы будем создавать новую. Жмем “Ок”, подтверждая создание ветки. Теперь переключаемся на свой новый branch.

Выбираем в меню “TortoiseGit – Switch/Checkout…“:

В открывшемся окне выбираем нашу новую ветку и жмем “Ок”. Убеждаемся, что мы успешно переключились:

По сути, все что касалось создания нового branch’a в консоли решилось бы всего одной командой:

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

5. Вносим изменения в репозиторий. После того как внесены какие-то изменения нам необходимо их закрепить в Git. И здесь опять же проявляется отличие этой системы контроля версий от того же SVN. Дело в том, что Commit в Git не сбрасывается сразу на сервер. Для того, чтобы внести изменения в удаленный репозиторий используется команда PUSH. В общем виде работа может быть построена следующим образом:

1. Вносятся изменения в проект

2. Изменения закрепляются в вашем локальном репозитории, используя команду Commit в меню или, используя консоль:

3. Когда Вам необходимо/удобно/требуется закрепить все изменения на сервере выполняем push в свою ветку (brunch). Команда консоли выглядит так:

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

Для этого выбираем новый файл, вызываем меню и выбираем “Add…”:

По рисунку можно видеть, что я вношу в индекс новый файл text.txt. Жмем “Ok”.

После того как файл добавлен, можно сразу же сделать Commit – кнопка Commit появится в окне с выводом консоли. Жмем её и откроется окно для внесения Commit’a:

Заполняем поле с описанием, жмем “Ок”  и коммит готов. Если хотите сразу отправить эти изменения в репозиторий, то в окне с выводом консоли появится также кнопка PUSH. Если же Вас не устраивает таскать по 1 файлику туда-сюда или изменения столь незначительны, что их нет смысла отправлять на сервер, то просто продолжаете дальше кодить, а push выполним позднее.

Чтобы выполнить команду push можете поступить следующим образом:

1. Зажимаем Shift и вызываем контекстное меню. В меню должны появится дополнительные команды:

Выбираем команду Push. Перед Вами откроется окно следующего содержания:

Все, что от Вас требуется на данном этапе – нажать на кнопку (на рисунке она выделена красным) найти в списке удаленную ветку в которую вы делаете push и два раза нажать Ok. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.

Зачем новичку учить Git

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

• Новый человек приходит в компанию и клонирует репозиторий проекта на ПК.
• Получает задачу, создаёт новую ветку и пишет код.
• Когда всё готово — отправляет запрос на добавление кода в master-ветку.
• Другие разработчики смотрят код, оставляют комментарии и указывают на ошибки.
• Новичок дорабатывает код, обновляет master-ветку и переходит к следующей задаче.

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