Создание новой ветви в командной строке
Программа Git в командной строке предлагает максимальную мощность и гибкость, но есть чему поучиться. Если вам удобно копаться в man-страницах и активно использовать Git, это отличный вариант.
Используйте команду git branch <branchname>, чтобы создать новую ветку с заданным именем:
Это ответвление от текущей ветви, поэтому убедитесь, что вы переключились на ту, от которой хотите перейти, прежде чем выполнять эту команду.
Вы можете перечислить все ветки и подтвердить, что новая была создана, с помощью git branch без каких-либо аргументов:
Вы можете увидеть дополнительную информацию, в том числе, какую ветвь отслеживает другая, используя флаг -vv :
Если вы попытаетесь создать ветку до первой фиксации, вы получите сообщение об ошибке, например:
Если вы попытаетесь создать ветку с уже существующим именем, вы получите сообщение об ошибке, например:
Команда git branch создает новую ветку, указывающую на тот же коммит, над которым вы сейчас работаете. Однако ваша рабочая копия по-прежнему будет указывать на основную ветку. Чтобы переключиться на новую ветку, которую вы только что создали, используйте git checkout :
Термин « проверка» может сбивать с толку, если вы привыкли к другим системам контроля версий; в Git проверка относится к переключению текущей активной ветки. Поскольку вы обычно хотите переключиться на новую ветку после ее создания, для всего процесса есть ярлык:
Эта команда означает «создать новую ветку под названием« dev »и немедленно переключиться на нее». Это эквивалент:
Фактически, вы даже можете использовать git checkout для создания ветки из любой другой, а не только из той, которая в данный момент проверена. Например, чтобы создать новую ветку с именем another , из ветки с именем dev :
Создание новой ветки с помощью GitHub Desktop
GitHub Desktop всегда будет показывать вашу текущую ветку на главной панели инструментов:
Нажмите эту кнопку на главной панели инструментов, чтобы отобразить подробную информацию о ветвях репозитория, включая возможность создания новой ветки:
Обратите внимание, что, если вы начнете вводить имя ветки без совпадений, GitHub Desktop предложит вам создать новую ветку и покажет сочетание клавиш для этого – полезно, если вы действительно много делаете этого:
Вы также можете начать, сразу же нажав кнопку New Branch . Какой бы маршрут вы ни выбрали, у вас появится диалоговое окно для подтверждения нового имени ветки:
Ваша новая ветка всегда будет основана на той ветке, которая была активна, когда вы ее создали. GitHub Desktop переключится на вашу новую ветку, которая будет автоматически отслеживать ветку, из которой вы ее создали.
Работа со своим первым репозиорием 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. Все изменения, произведенные Вами в локальном репозитории отправятся в Сеть.
Качаем и устанавливаем софт
- msysgit – качаем Git For Windows
- TortoiseGit. На момент написания статьи последней была версия (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.
Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.
Вначале ставим msysgit, а потом TortoiseGit.
При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне “Choose SSH Client” второе значение:
После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму – получение доступа к репозиторию Git.
Шаг 1 — Знакомство с вкладкой Source Control
Прежде всего, чтобы воспользоваться преимуществами интеграции контроля исходного кода, следует инициализировать проект как репозиторий Git.
Откройте Visual Studio Code и запустите встроенный терминал. Вы можете открыть его, используя сочетание клавиш в Linux, macOS или Windows.
Используя терминал, создайте каталог для нового проекта и перейдите в этот каталог:
Затем создайте репозиторий Git:
Также вы можете сделать это в Visual Studio Code, открыв вкладку Source Control (иконка выглядит как развилка дороги) в левой панели:
Затем нажмите кнопку Open Folder:
При нажатии кнопки откроется проводник файлов, где будет открыт текущий каталог. Выберите предпочитаемый каталог проекта и нажмите Open.
Затем нажмите Initialize Repository:
Если теперь вы посмотрите на свою файловую систему, вы увидите, что она содержит каталог . Чтобы сделать это, используйте терминал для перехода в каталог проекта и вывода его содержимого:
Вы увидите созданный каталог :
Это означает, что репозиторий инициализирован, и теперь вам следует добавить в него файл .
После этого на панели Source Control вы увидите, что рядом с именем вашего нового файла отображается буква U. Обозначение U означает, что файл не отслеживается, то есть, что это новый или измененный файл, который еще не был добавлен в репозиторий:
Вы можете нажать значок плюс (+) рядом с файлом , чтобы включить отслеживание файла в репозитории.
После этого рядом с файлом появится буква A. A обозначает новый файл, который был добавлен в репозиторий.
Чтобы записать изменения, введите команду отправки в поле ввода в верхней части панели Source Control. Затем нажмите иконку отметки check для отправки файла в репозиторий.
После этого вы увидите, что несохраненных изменений нет.
Теперь добавьте немного содержания в файл .
Вы можете использовать ярлык Emmet для генерирования базовой структуры кода HTML5 в VS Code, нажав , а затем клавишу . Теперь добавьте что-нибудь в раздел , например, заголовок , и сохраните файл.
На панели исходного кода вы увидите, что ваш файл изменился. Рядом с именем файла появится буква M, означающая, что файл изменен:
Для практики давайте запишем это изменение в репозиторий.
Теперь вы познакомились с работой через панель контроля исходного кода, и мы переходим к интерпретации показателей gutter.
Получаем доступ к репозиторию
В качестве примера я буду рассматривать получение доступа к нашему репозиторию, который располагается на
Распишем все операции по шагам.
1. Регистрация на GitHub’e.
Профиль на GitHub.com
2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык – Git Bush – вот с помощью него и запускаем консоль.
- Набираем в консоли следующую команду
- На экране появится запрос “Enter file in which to save the key”. Пока оставим значение по умолчанию. Жмем Enter.
- Нас попросят ввести пароль. Эту часть тоже пропускаем – впоследствии пароль можно будет установить, а пока – учимся. Жмем опять Enter.
- Сгенерируются два файла один из которых – публичный ключ для доступа.
Если Вы все делали с настройками по умолчанию то файлы будут располагаться в директории:
Заходим в директорию, открываем с помощью “Блокнота” файл ida_rsa.pub и копируем все его содержимое в буфер обмена.
3. Заносим публичный ключ доступа в профиль.
Для записи публичного ключа в профиль:
- Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
- Выбираем пункт “SSH Public Keys”
- Жмем ссылку “Add another public key”
Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key – поле Title оставляем пустым.
На этом работа с публичными ключами закончена.
4. Просимся в проект.
Дай мне этот проект!
Возможно, вы захотите клонировать свой новый репозиторий, чтобы вы могли работать с ним на локальном компьютере, или у вас может быть существующий репозиторий, который вы хотите клонировать. (Это то, что вам может понадобиться для проекта или курса.)
Для того, чтобыклонировать хранилищена свой компьютер, перейдите в репозиторий на веб-сайте GitHub и нажмите большую зеленую кнопку с надписью «Клонировать или скачать». (Вы можете загрузить репозиторий прямо здесь и пропустить содержимое терминала, если просто не можете с этим справиться. Но я верю в вас, поэтому продолжайте!) Убедитесь, что на нем написано «Клонировать с HTTPS». Теперь щелкните значок буфера обмена, чтобы скопировать его и вставить в буфер обмена (или выделите эту ссылку и скопируйте ее).
Клонировать или скачать репозиторий
Теперь вы откроете свойТерминали доберитесь до места, где вы хотите, чтобы этот хранилище приземлилось. Вы можете, например, набрать
cd Desktop
чтобы попасть на рабочий стол. Затем клонируйте свой репозиторий, чтобы его было легко найти. Чтобы клонировать репозиторий, вы набираете
git clone <that_thing_you_just_copied>
Просто! (Не забудьте изменить информацию междуотметки к той строке букв и цифр, которые вы только что скопировали! Также убедитесь, что вы удалили.)
Теперь у вас есть новый репозиторий GitHub, с которым вы можете работать клонировано прямо на вашем рабочем столе! Эта команда вытащила полную копию хранилища прямо в вашу систему, где вы можете работать с ней, вносить изменения, вносить изменения, фиксировать изменения, а затем отправлять изменения обратно в GitHub.
Если вы когда-нибудь захотите поиграть с проектом самостоятельно, вы можетевилкаэто на сайте GitHub вместо клонирования. Найдите в правом верхнем углу экрана кнопку «вилка» и нажмите ее. Это сделает копию репозитория в ваших репозиториях, чтобы вы могли играть самостоятельно, не делая ничего с оригиналом.
GitHub поток
Допустим, у вас есть проект, и у вас может быть много разных идей и возможностей в любой момент времени. Некоторые функции могут быть готовы к работе, а некоторые нет. Может быть, вы работаете с другими людьми, которые все делают свое дело. Вот где начинается ветвление!
Филиал — это отдельное пространство, где вы можете опробовать новые идеи. Если вы что-то измените в ветке, это не повлияет на основную ветку, пока вы этого не захотите. Это означает, что вы можете делать с этой веткой все, что захотите, пока не решите, что пришло время объединить ее.
Единственная ветвь, которая собирается навсегда изменить вещи, является основной ветвью. Если вы не хотите, чтобы ваши изменения были развернуты немедленно, внесите их в отдельную ветку и объедините их с основной веткой, когда будете готовы.
Если вы работаете с другими и хотите вносить изменения самостоятельно, или если вы работаете самостоятельно и хотите вносить изменения, не затрагивая основную ветку, вам нужна отдельная ветка. Вы можете создать новую ветку в любое время.
Также довольно просто создать ветку с именем «new_feature» в вашем терминале и переключиться на нее с помощью
git checkout -b new_feature
Как только вы создадите ветку, вы можете внести изменения в эту ветку. Это позволяет легко увидеть, что вы изменили и почему вы это изменили. Каждый раз, когда вы фиксируете свои изменения, вы добавляете сообщение, которое вы можете использовать для описания того, что вы сделали.
Давайте поговорим об оформлении заказа!
git checkout
позволяет проверить хранилище, в котором вы в данный момент не находитесь. Вы можете проверить мастер ветку с
git checkout master
или посмотрите на ветку «new_feature» с
git checkout new_feature
Когда вы закончили работу с веткой, вы можете объединить все свои изменения обратно, чтобы они были видны всем.
git merge new_feature
возьмет все изменения, которые вы внесли в ветку «new_feature», и добавит их в мастер.
Чтобы создать восходящую ветвь, чтобы вы могли отправить свои изменения и установить удаленную ветвь как восходящую, вы добавите свою функцию, запустив
git push --set-upstream origin new_feature
После того, как вы внесете некоторые изменения и решите, что они вам нравятся, вы открываете запрос на включение. Если вы в команде, это когда другие люди в вашей команде могут начать проверять ваши изменения и обсуждать их. Вы можете открыть запрос на удаление в любой момент, будь то, чтобы люди просмотрели ваши окончательные изменения или попросили о помощи, потому что вы застряли на чем-то.
Как переключиться на чью-то ветку из удаленного репозитория
Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой — вы создаете локальную копию чужой ветки, и над ней уже работаете
Но для начала надо обновить локальный репозиторий — скопировать в него все ветки, которые есть в удаленном репозитории:
git fetch
Теперь можно посмотреть, какие ветки есть в удаленном репозитории:
git branch -v -a
Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:
git checkout -b dev1 origin/dev1
Вообще-то можно было написать проще:
git checkout dev1
Но:
- Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
- Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:
git checkout -b mydev1 origin/dev1
¶ Поиск коммитов по разным критериям
Команда имеет большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
- Одним из самых полезных аргументов является или , который показывает разницу (выводит патч), внесенную в каждый коммит. Вы можете ограничить количество записей в выводе команды; используйте параметр для вывода только двух записей:
Эта опция отображает аналогичную информацию, но содержит разницу для каждой записи. Удобно использовать данную опцию для код ревью или для быстрого просмотра серии внесенных изменений.
- Существует возможность использовать серию опций для обобщения. Например, если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию :
Опция печатает под каждым из коммитов список и количество измененных файлов, а также сколько строк в каждом из файлов было добавлено и удалено.
- Рассмотрим опцию . Она меняет формат вывода. Существует несколько встроенных вариантов отображения:
- Опция выводит каждый коммит в одну строку, это удобно, если вы просматриваете большое количество коммитов.
- Опции , и делают вывод приблизительно в том же формате, но с меньшим или большим количеством информации соответственно:
Опция format позволяет указать формат для вывода информации. Это полезно, когда вы хотите сгенерировать вывод для автоматического анализа. Так как вы указываете формат явно, он не будет изменен даже после обновления Git:
Полезные опции для отображает наиболее полезные опции для изменения формата.
- Наиболее распространенные опции для команды содержат описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
Разница между автором и коммитером.
Автор – это человек, изначально сделавший работу, а коммитер – это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника: вы как автор и основной член команды как коммитер.
Мне уже удобно с терминалом (Вариант 1)
Вот как вы можете начать прямо с терминала:
Если у вас есть каталог проекта, просто перейдите к своему терминалу и в вашем каталоге проекта выполните команду
git init
Если вы хотите инициализировать ваш проект со всеми файлами в каталоге вашего проекта, запустите
git init .
включить все.
Допустим, у вас есть папка для вашего проекта с именем «new_project». Вы можете перейти к этой папке в окне терминала и добавить в нее локальный репозиторий, запустив
cd new_projectgit init
Теперь у вас есть новый скрытый каталог с именемв каталоге вашего проекта. Здесь Git хранит то, что ему нужно, чтобы он мог отслеживать ваш проект. Теперь вы можете добавлять файлы в область подготовки один за другим с
git add <filename_one>
или беги
git add .
чтобы добавить все ваши файлы в область подготовки. Вы можете зафиксировать эти изменения с помощью команды
git commit -m "<add a commit message here>"
и если вы довольны своими изменениями, вы можете запустить
git push
протолкнуть ваши изменения до конца. Вы можете проверить, есть ли у вас изменения, чтобы протолкнуть в любое время, запустив
git status
Если вы внесли некоторые изменения, вы можете обновлять файлы одновременно с
git add <filename>
или
git add --all
Затем передайте их с вашим сообщением и протолкните их.
Это оно! Теперь вы можете инициализировать репозиторий, фиксировать файлы, фиксировать изменения и передавать их в основную ветку.
Если у вас есть это, просто прокрутите вниз до «Учимся работать с другими »перейти к ветвлению и сотрудничеству!
фотоДжонатан ДэниелснаUnsplash
Что такое Git Branch?
В системах управления версиями термин « ветвь» используется как аналогия с деревьями в том смысле, что каждая ветвь возникает из другой и в конечном итоге возвращается в ствол. Филиалы позволяют создавать отдельные линии разработки, чтобы работать над ними изолированно, не мешая другой работе.
Используя Git, вы по умолчанию будете работать с основной веткой, знаете ли вы об этом или нет. Это часто называют вашей активной , текущей , проверенной веткой или HEAD . В любой момент в течение цикла разработки вы можете создать новую ветку и с этого момента выполнять отдельную работу в каждой ветке.
Навигация
Прежде чем перейти к более продвинутым фичам Git, важно понять различные способы перемещения по коммитам вашего проекта
Detaching HEAD
Давайте разберемся, как нам откатиться к более старой версии нашего репозитория.
У git есть указатели на коммиты, своеобразный ярлыки, которые перемещаются от коммита к коммиту. Одним из таких ярлыков-указателей является .
— это символическое имя текущего выбранного коммита. По сути это, тот коммит, над которым мы в данным момент работаем.
Указатели могут ссылаться на другие указатели, обычно указывает на имя ветки. Но это можно изменить, например указать hash нужного коммита, чтобы откатиться к нему.
Создадим еще один файл и сделаем третий коммит:
Мы видим, что сейчас указывает на , это тоже указатель, обозначающий ветку. То есть указывает на , который в свою очередь указывает на коммит . Отделение (detaching) означает лишь присвоение его не ветке, а конкретному коммиту.
Представим, что нам надо посмотреть, как выглядел наш репозиторий после второго коммита. Для этого используем команду и хэш второго коммита. Кстати, можно не указывать его целиком, достаточно первых 5 символов.
Таким образом мы переключились на состояние второго коммита, в котором у нас еще не было файла , проверим это:
Вызвав видим, что теперь указывает на второй коммит:
При этом мы не потеряли третий коммит и все изменения в нем, можем убедиться в этом с помощью следующей команды:
Вернем указатель на :
Относительные ссылки
Передвигаться по коммитам при помощи указания хешей неудобно. Поэтому Git поддерживает относительные ссылки. С относительными ссылками можно начать с какого-либо удобного места и двигаться от него.
Относительные ссылки — мощный инструмент, но мы разберем два простых способа использования:
- Перемещение на один коммит назад
- Перемещение на n коммитов назад
Для начала рассмотрим оператор каретки . Когда мы добавляем его к имени указателя, Git воспринимает это как команду найти родителя выбранного коммита. Так что означает “первый родитель ветки main”. означает прародитель (родитель родителя) .
Давайте переключимся на коммит выше :
Да, мы снова попали на второй коммит, то есть сейчас вновь указывает на второй коммит.
Может показаться, нужно еще раз вызвать команду , чтобы попасть на первый коммит. Но это не так, указатель остался на третьем коммите, мы сдвинули . Поэтому запросит снова родителя третьего коммита.
Чтобы попасть на первый коммит, можно использовать указатель . Попробуем перейти к первому коммиту:
Вернемся на третий коммит:
.gitignore
Команда git status в модуле Git очень доступна, и пользователи могут использовать ее чаще всего. Но иногда пользователи могут обнаружить, что есть пара файлов, которые отображаются в не отслеживаемом разделе модуля git, и они не хотят, чтобы модули git видели их. Для этого пользователь может использовать файл .gitignore.
Например:
#Let's create a new Python file of the project in the same directory called example.py: #example.py Def get_example( ) : return " cow "
После этого измените файл sample.py, включив в него example.py, и вызовите его функцию:
#sample.py import example example = example.get_example( ) print( " Animal { } " .format(example) )
Каждый раз, когда пользователь импортирует локальный модуль, Python начинает компилировать модуль в байтовый код и сохраняет файл в своей файловой системе. В Python2 после компиляции модуля в байт-код он сохранит файл в виде example.pyc. Но в случае с python3 он сгенерирует каталог _pycache_ и сохранит в нем файл .pyc.
Например:
После этого, если пользователь запустит команду git status, он увидит, что этот конкретный каталог присутствует в неотслеживаемом разделе. Пользователи также могут видеть, что их файл example.py находится в неотслеживаемом разделе, но изменения, которые они внесли в sample.py, находятся в новом разделе, который известен как «Изменения, не предназначенные для фиксации». Этот раздел означает, что изменения, сделанные пользователем ранее, не были добавлены в промежуточную область модуля git.
Пример:
$ git status
Чтобы добавить файлы example.py sample.py в репозиторий, пользователь должен сделать то же самое, что и раньше.
Например:
$ git add example.py sample.py $ git status
Теперь пользователь должен зафиксировать изменения и завершить очистку:
$ git commit -m " add example module "
всякий раз, когда пользователь запускает команду git status, он будет видеть каталог _pycache_ следующим образом:
$ git status
если пользователь хочет, чтобы весь каталог _pycache_ и его содержимое игнорировались, он должен добавить файл .gitignore в свой репозиторий. Это очень простой процесс. Пользователи должны редактировать файл в выбранном ими редакторе.
# .gitignore __pycache__
Затем пользователи должны запустить команду git status, и они больше не увидят каталог _pycache_ и его содержимое. Хотя пользователь увидит новый .gitignore! файл.
Например:
$ git status
Файл .gitignore – это обычный текстовый файл, и его можно добавить в репозиторий, как и другие обычные файлы.
Например:
$ git add .gitignore $ git commit - add " create .gitignore "
В файле .gitignore есть еще один вход, который представляет собой каталог, который пользователь хранит в своих виртуальных средах. Этот каталог называется virtualenvs. Каталог virtualenvs обычно известен как env или venv.
Пользователи могут добавлять их в свои файлы .gitignore проекта. При этом каталог или файлы проекта, присутствующие в репозитории, будут проигнорированы. И если нет файла или каталога, то никаких действий выполняться не будет.
Пользователи также могут хранить глобальный файл .gitignore в своем домашнем каталоге. Этот процесс очень прост, если редактор пользователя использует для сохранения временных файлов или создает резервные копии файлов в локальном каталоге компьютерной системы.
Пример:
# .gitignore __pycache__ Venv Venv / Venv.bak / env / env.bak / .pytest_cache .cover / .coverage
Создание копии репозитория
Репозиторий – это главная папка проекта. Репозиторий содержит все файлы проекта, включая документацию и хронологию изменений для каждого файла. Репозитории на GitHub могут иметь несколько соавторов, также они могут быть публичными и приватными.
Чтобы начать работу над открытым проектом, нужно сначала создать собственную копию репозитория. Чтобы получить локальную рабочую копию кода, создайте форк проекта (ветвление, fork) и клонируйте его.
Форк проекта
Чтобы создать форк репозитория GitHub, откройте сайт GitHub и найдите открытый проект, в разработке которого вы хотите участвовать. Ссылки GitHub содержат имя владельца проекта и название самого проекта.
К примеру, репозиторий проекта node-chakracore принадлежит nodejs, значит, ссылка GitHub будет выглядеть так:
где nodejs – имя пользователя, node-chakracore – имя репозитория.
Выберите проект, в котором вы хотите принять участие, и откройте его репозиторий на GitHub.
На главной странице проекта вы увидите кнопку Fork под вашим значком пользователя.
Чтобы начать форк репозитория, нажмите кнопку Fork. В окне браузера появится следующее сообщение:
Когда процесс будет выполнен, в браузере вы увидите такой же репозиторий, как и раньше, но в ссылке уже будет указано ваше имя.
Теперь можно клонировать репозиторий и получить локальную копию кода.
Клонирование репозитория
Чтобы создать локальную копию кода проекта, откройте терминальное окно. Используйте команду git clone и укажите ссылку на форк репозитория.
Эта ссылка почти такая же, как и предыдущая, и отличается только тем, что заканчивается расширением .git, например:
Скопировать эту ссылку можно с помощью зелёной кнопки Clone or download на странице репозитория. Справа от ссылки появится кнопка, с помощью которой можно скопировать ссылку.
Теперь можно добавить скопированный URL в команду git clone:
Что значит «смёржить» (git merge)
Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.
Получается, что схема работает так:
- Запускаем в мастере рабочий код с первой версией сайта, которая автоматически отправляется в продакшен (на сборку).
- Создаём новую ветку на основе мастера.
- В этой новой ветке пишем новый код, который добавит интерактивные функции на сайт.
- Тестируем эту ветку как отдельный проект.
- Если всё в порядке — смёрживаем её в мастер и получаем сразу готовую сборку сайта с новыми возможностями.