Еще одна инструкция по пользованию git

Что такое Git?

Git — система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?

Представьте, что вы с коллегами вместе пишете ядро Linuxнаучную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста — последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:

• Ваша папка на компьютере — это не просто папка, а локальный репозиторий.
• Она является копией удалённого репозитория, который лежит на веб-хостинге (например, GitHub или BitBucket).
• Eсли вы работаете над проектом с коллегами, то своя локальная копия есть у каждого.
• Kогда вы внесли некоторое количество изменений, вы можете их сохранить, и это действие запишется в журнал; это называется commit (коммит).
• После этого можно отправить изменения в удалённый репозиторий; это называется push (пуш, пу́шить, запу́шу, пуши́ от души).
• Актуальная версия проекта, учитывающая последние изменения всех участников, будет храниться в удалённом репозитории.
• Если вы увидели, что ваши коллеги запушили в удалённый репозиторий что-то новенькое, то можно (и нужно!) “скопировать” это себе на компьютер (в локальный репозиторий); это называется pull (пулл).

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

Понятно, что для совместной работы над текстом научной статьи вполне хватит и Google Docs, но вот если, например, вы хотите опубликовать результаты исследования в интернете и сделать для этого собственный сайт, то без VCS обойтись сложно. И ещё раз, системы контроля версий хороши тем, что:

• они позволяют работать над проектом в команде;
• вы видите, кем и когда были внесены те или иные изменения;
• их всегда можно откатить назад;
• вы не потеряете проделанную работу, даже если что-то удалите на своем компьютере;
• ваши наработки могут быть полностью открыты для других (а это доступность знаний и ускорение развития технологий, ура!);
• GitHub и GitLab позволяют не только хранить и просматривать файлы проекта, но и публиковать веб-сайты, документацию и т.п.

Существует много систем управления версиями, но мы будем пользоваться самой распространенной — git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы — это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:

• TortoiseGit
• GitKraken
• GitHub Desktop
• Fork
• Git GUI
• Git Extensions
• SourceTree

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

Итого:

• Git — разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
• Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
• Репозиторий — это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

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

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

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

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

git clone http://user@somehost:port/~user/repository/project.git

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

git clone /home/username/project myrepo

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

git clone ssh://user@somehost:port/~user/repository

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

git clone git://user@somehost:port/~user/repository/project.git/

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

git svn clone -s http://repo/location

-s

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

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

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

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

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

git merge username-project/master

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

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

git pull

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

git pull username-project --tags

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

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

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

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

git push

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

git push ssh://yourserver.com/~you/proj.git master:experimental

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

git push origin :experimental

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

git push origin master:master

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

git push origin master --tags

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

git push origin origin/develop:master

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

git push origin origin/develop:refs/heads/test

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

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

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

Что же делать, если не ? Наиболее простое решение — взять и закоммитить всё с комментарием (распространённая аббревиатура от «Work In Progress»). Не надо морочить себе голову, вспоминать названия команд и искать потом, в который из стешей сохранены изменения.

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

Step 6: Create a new repository on GitHub

If you only want to keep track of your code locally, you don’t need to use GitHub. But if you want to work with a team, you can use GitHub to collaboratively modify the project’s code.

To create a new repo on GitHub, log in and go to the GitHub home page. You can find the “New repository” option under the “+” sign next to your profile picture, in the top right corner of the navbar:

After clicking the button, GitHub will ask you to name your repo and provide a brief description:

When you’re done filling out the information, press the ‘Create repository’ button to make your new repo.

GitHub will ask if you want to create a new repo from scratch or if you want to add a repo you have created locally. In this case, since we’ve already created a new repo locally, we want to push that onto GitHub so follow the ‘….or push an existing repository from the command line’ section: 

(You’ll want to change the URL in the first command line to what GitHub lists in this section since your GitHub username and repo name are different.)

push

Отправить новые данные на удалённый репозиторий

$ git push origin master

Enumerating objects: 83, done.
Counting objects: 100% (83/83), done.
Delta compression using up to 4 threads
Compressing objects: 100% (81/81), done.
Writing objects: 100% (83/83), 3.36 MiB | 3.19 MiB/s, done.
Total 83 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To https://github.com/andreiolegovichru/travel-site.git
* master -> master

Если нужно делать push из другой ветки — просто напишите её называние вместо master

git push origin some/other/branch_name

Enumerating objects: 30, done.
Counting objects: 100% (30/30), done.
Delta compression using up to 8 threads
Compressing objects: 100% (26/26), done.
Writing objects: 100% (26/26), 6.32 KiB | 6.32 MiB/s, done.
Total 26 (delta 7), reused 0 (delta 0)
remote:
remote: To create a merge request for some/other/branch_name, visit:
remote: https://gitlab.yourcompany.com/Project/Project/merge_requests/new?merge_request%5Bsource_branch%5D=some%2Fother%2Fbranch_name
remote:
To gitlab.ssh.com:IAM/IAM.git
abcdefdc8..abcdef000 topic/qa/init_perf_test_controller -> topic/qa/init_perf_test_controller

Метрики CI/CD в GitLab

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

Хорошей новостью является то что GitLab имеет функционал сбора этой статистики. Давайте с этим функционалом познакомимся.

! Кликните на Analytics. По умолчанию откроется раздел Value stream. В Lean вообще и в DevOps в частности считается что задачи несут в конечном итоге некоторую пользу для конечного заказчика. И движение таких полезных задач, от стадии формулирования через все этапы работы до того момента когда результаты становятся доступны заказчику называется value stream.

Основные средние величины по этапам:

• Issue — время которое уходит на то чтобы задачу «взять в работу» т.е. присвоить метку или добавить в Milestone.
• Plan — время от последнего действия в предыдущем этапе до появления первого коммита в ветке, хоты бы один из коммитов которой связан с той же задачей. То есть «время, которое уходит чтобы начать коммитить».
• Code — время существования ветки, связанной с той или иной задачей, которое уходит до появления merge request’a.
• Test — время от начала до конца всех конвейеров данного проекта.
• Review — время от создания merge request’а до его слияния или закрытия.
• Staging — время от принятия merge request до развёртывания в продуктивную среду.

Если вы сложите длительность Issue, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).

Наверху страницы в также увидите некие агрегатные показатели по проекту за выбранный период времени.

Analytics -> Repository показывает разные графики связанные с языками коммитов, показателями code coverage (если настроено), распределением коммитов во времени (месяц, дни недели, часы).

Analytics -> CI/CD показывает сводные данные по выполенным pipelines, в том числе график показывающий динамику изменения «успешности» выполнения pipelines.

Умный HTTP

Теперь у нас есть доступ с аутентификацией через SSH и неаутентифицированный доступ через , но есть ещё протокол, который может делать и то и другое.
Настройка умного HTTP — это просто установка на сервер CGI-скрипта , поставляемого вместе с Git.
Этот CGI-скрипт будет читать путь и заголовки, посылаемые или в URL и определять, может ли клиент работать через HTTP (это верно для любого клиента, начиная с версии 1.6.6).
Если CGI-скрипт видит, что клиент умный, то и общаться с ним будет по-умному, иначе откатится на простое поведение (что делает операции чтения обратно совместимыми со старыми клиентами).

Давайте пройдёмся по самой базовой установке.
Мы настроим Apache как сервер CGI.
Если у вас не установлен Apache, вы можете сделать это на Linux-машине примерно так:

Это также включит необходимые для корректной работы модули , и .

Так же необходимо установить Unix пользователя и группу для каталога в значение , чтобы позволить веб-серверу читать из и писать в репозитории, потому что процесс Apache, запускающий CGI скрипт, работает от имени этого пользователя:

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

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

Наконец, нужно разрешить Apache обрабатывать запросы к , при этом запросы на запись должны быть авторизованы, для этого можно использовать вот такой блок конфигурации:

Это потребует создания файла , содержащего пароли всех пользователей.
Например, добавление пользователя «schacon» в этот файл делается так:

Существует множество способов аутентифицировать пользователей в Apache, вам нужно выбрать и применить хотя бы один из них.
Мы привели простейший пример.
Скорее всего вы ещё захотите настроить SSL для шифрования траффика.

Мы не хотим погружаться слишком глубоко в бездну настроек Apache, так как у вас может быть другой сервер или другие требования к аутентификации.
Идея в том, что Git идёт с CGI-скриптом , который берет на себя согласование передачи и приёма данных по HTTP.
Сам по себе, он не реализует аутентификации, но это легко настраивается на уровне веб-сервера, который его запускает.
Вы можете сделать это практически на любом веб-сервере с поддержкой CGI, так что используйте тот, который знаете лучше всего.

Примечание

За дополнительной информацией по настройке аутентификации в Apache обратитесь к документации: https://httpd.apache.org/docs/current/howto/auth.html

prev | next

Шаг 1: Зарегистрируйтесь и установите!

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

Теперь зайдите в свой терминал и представьтесь Git! Чтобы установить ваше имя пользователя длякаждый репозиторийна вашем компьютере введите

git config --global user.name "<your_name_here>"

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

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

git config --global user.email "<>"

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

Теперь вы готовы начать использовать Git на своем компьютере!

фотоМэтти АдамнаUnsplash

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

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

Добавляем и изменяем файлы

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

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

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов — это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Что такое Git? Что такое GitHub?

ГитВ настоящее время это технология контроля версий, которая подходит практически всем, от разработчиков до дизайнеров.GitHubэто социальная платформа для размещения кода, которая в настоящее время используется чаще, чем любая другая. Это место, где вы можете играть и экспериментировать. Это место, где вы можете найти (и поиграть) самую невероятную информацию с открытым исходным кодом, новейшие технологии, функции и проекты. Это место, где нужно учиться, и место, где можно принять участие. Вы можете хранить код там для работы или для школы, и вы можете взять какой-нибудь приятный код, который вы хотите изучить дальше. Вы даже можете размещать сайтыпрямо из вашего хранилища! (Если вы хотите знать, как это сделать, прочитайте эту статью!)

фотоДжейми ХотоннаUnsplash

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

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

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

git clonegit statusgit addgit commit -m “ “git push

Это оно! Это большие! Если у вас есть с этим справиться, вам хорошо идти. Вы можете начать работу над своими проектами немедленно!

фотоДелани ДоусоннаUnsplash

Мы также поговорим о

git initgit branchgit mergegit checkout

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

также очень полезно, если вы только начинаете! Мы тоже это обсудим.

(Если вы работаете на Mac, у вас уже есть терминал! Вы можете найти его, щелкнув по значку увеличительного стекла в верхнем правом углу экрана и выполнив поиск по слову «терминал».)

Эмммм… это делается через сайт?

Да, все это делается с сайта GitHub.

Pull request создается по нажатию одноименной кнопки, о которой мы говорили ранее при редактировании README-файла. Элементарно!

А еще вы можете создать отдельную ветку на сайте через сам репозиторий. Перейдите в репозиторий и кликните по выпадающему меню в левой части экрана. Там еще написано Branch: master. Задайте имя новой ветки и выберите Create branch (либо нажмите на клавиатуре). Теперь у вас есть две одинаковые ветки. Это отличное место для внесения изменений и тестирования их до слияния с .

Создание ветки

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

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

Pull request можно открыть сразу при создании коммита, даже если вы все еще работаете с кодом. Делается это с сайта GitHub. Допустим, вы внесли изменения в ветку и хотите слить их с . Тогда:

• Кликните по вкладке Pull request вверху экрана.
• Нажмите зеленую кнопку New pull request.
• Перейдите в поле Example Comparisons. Выберите ветку, которую хотите сравнить с .
• Еще раз просмотрите все изменения, убедитесь, что они готовы для коммита.
• Нажмите большую зеленую кнопку New pull request. Напишите заголовок запроса, дайте краткое описание изменений. Нажмите Create pull request.

Новый Pull request

Создание pull request

Если это ваш репозиторий, то слить изменения с можно через зеленую кнопку Merge pull request. Нажмите Confirm merge. Сразу после объединения нужной ветки с нажмите Delete branch в фиолетовом боксе.

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

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

Я не знаю, что вы только что сказали (Вариант 2)

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

Давайте сделаем это!

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

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

Это хорошая идея, чтобы включитьПРОЧТИ МЕНЯфайл с информацией о вашем проекте. Вы можете создать один в то же время, когда вы создаете свой репозиторий, щелкнув флажок.

• Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
• Назовите репозиторий и добавьте краткое описание.
• Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
• Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)

Новый репозиторий
Создание вашего нового хранилища

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

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

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

• Сначала зайдите в свой репозиторий.
• Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
• Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
• Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
• Нажмите кнопку «Подтвердить изменения»

Редактирование вашего файла на GitHub
Передача ваших изменений

Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!). Довольно легко, правда?

Довольно легко, правда?

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

Sprout (ранее GitMac)

Ориентация на создание git проста в использовании. Имеет собственный пользовательский интерфейс Cocoa (mac-like), быстрый просмотр репозитория, клонирование, push/pull, разветвление/слияние, визуальный diff, удаленные ветки, легкий доступ к терминалу и т.д.

Используя наиболее часто используемые действия git, интуитивно понятные и легко выполняемые, Sprout (ранее GitMac) делает git удобным для пользователя. Совместимость с большинством рабочих процессов git, Sprout отлично подходит для разработчиков и разработчиков, коллективной работы и продвинутых и начинающих пользователей.

Загрузить | Веб-сайт

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

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

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

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

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

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

Посмотреть, что я добавил в stage

Замечание: сюда новые файлы попадают.

Удалить лишние файлы

Т.е. файлы, которые не относятся к репозиторию

• — удаляет еще и директории
• — обязательная опция, без нее гит попросту откажется что-либо удалять (уж не знаю, зачем она)

Отменить последний коммит

У меня на это дело есть alias в баше:

переносит ветку на коммит, но код не меняет. Разница заносится в stage.

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

выдаст хеши двух последних коммитов.

В общем, вся команда сводится к тому, что текущая ветка переносится на один коммит назад, а изменения, внесенные коммитом, попадают в stage

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

Объединить несколько коммитов

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

Решение:

Интерактивный rebase!

Это откроет текстовый редактор, в котором списком будут указаны коммиты.
Вы можете:

• Менять порядок их применения (очень часто пригождается)
• «Сквошить» — объединять несколько коммитов в один
• редактировать — гит будет останавливаться, чтобы вы могли делать изменения с помощью —amend
• менять сообщение — в общем-то, частный случай редактирования
• не применять коммит в принципе

В данной ситуации нужно взять нужные коммиты, расставить их друг за другом и всем, кроме первого, поставить пометку .

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

Добавить изменения в старый коммит (когда для —amend уже поздно)

Ситуация:

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

Решение:

Интерактивный rebase!

Лично я в указанной ситуации (а у меня она часто возникает) делаю так: создаю коммит, где в сообщении добавляю префикс, заканчиваю работу над веткой, делаю полный ребейз ветки на мастер () и переношу этот коммит под тот, к которому данная правка относится, с пометкой (squash).

Закоммитить части файла по отдельности

Коммиты желательно делать максимально простыми (антоним слову «сложными»). Хочу вот я на гитхабе посмотреть, какая история у файла , смотрю историю, а там среди прочих коммит «create super-booper feature», в котором в файле hello_world.rb у одной переменной изменено имя, хотя она к фиче совсем отношения не имеет. Лучше было бы наличие коммита «rename variable x to y in hello_world.rb».

Собственно, например, у меня есть код:

Мне нужно добавить фичу: выводить удвоенное n. Изи! Но пока я пишу фичу, на автомате меняю некрасивое имя функции.

Пишем:

Как теперь коммитить? Можно быстро вернуть старое название, закоммитить новый функционал, а потом уже переименовать, но это не всегда уместно, т.к. изменения могут быть достаточно крупными. Можно честно признать, что коммит сложный и написать сообщение в духе «добавил фичу + переименовал метод», но мы ведь стараемся делать коммиты простыми, верно?

Но у гита есть отличная команда:

Она интерактивная. Поочередно берет изменения кусками (hunk) и спрашивает, что с данным куском делать: игнорировать, добавить, изменить и добавить. Третий вариант достаточно мощный, можно по отдельности добавлять изменения даже в рамках одной строчки ( => в 2 коммита).

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

Заслуживают внимания

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

Outro

Я указал здесь всего-лишь парочку «трюков» работы с git, но их я использую на ежедневной основе.

Смысл данного поста (помимо того, чтобы ублажить свое ЧСВ и оставить заметку для себя самого) в том, чтобы еще раз подчеркнуть известную (относительно) фразу: Know your tools!.

Step 2. Create a Branch

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to .

When you create a branch off the branch, you’re making a copy, or snapshot, of as it was at that point in time. If someone else made changes to the branch while you were working on your branch, you could pull in those updates.

This diagram shows:

• The branch
• A new branch called (because we’re doing ‘feature work’ on this branch)
• The journey that takes before it’s merged into

Have you ever saved different versions of a file? Something like:

Branches accomplish similar goals in GitHub repositories.

Here at GitHub, our developers, writers, and designers use branches for keeping bug fixes and feature work separate from our (production) branch. When a change is ready, they merge their branch into .

To create a new branch

1. Go to your new repository .
2. Click the drop down at the top of the file list that says branch: main.
3. Type a branch name, , into the new branch text box.
4. Select the blue Create branch box or hit “Enter” on your keyboard.

Now you have two branches, and . They look exactly the same, but not for long! Next we’ll add our changes to the new branch.

Step 10: Get changes on GitHub back to your computer

Right now, the repo on GitHub looks a little different than what you have on your local machine. For example, the commit you made in your branch and merged into the primary branch doesn’t exist in the primary branch on your local machine.

In order to get the most recent changes that you or others have merged on GitHub, use the git pull origin master command (when working on the primary branch). In most cases, this can be shortened to “git pull”.

This shows you all the files that have changed and how they’ve changed.

Now we can use the git log command again to see all new commits.

(You may need to switch branches back to the primary branch. You can do that using the git checkout master command.)