Содержание

Git инструкция для начинающих. Работаем с GitHub

Это запись о том как быстро начать работу с Git’ом. Не какой воды.

Установка Git

Подробнее о том как установить Git я описал здесь:
https://techblog.sdstudio.top/blog/kak-ustanovit-git-v-windows 

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

git config --global user.name "John Doe" //Ваше имя
git config --global user.email "[email protected]" //Ваш e-mail
git config --global core.editor nano //Текcтовый редактор для git
git config --global merge.tool vimdiff //Утилита сравнения
git config --list //Проверка всех настроек

Настройка SSH-авторизации

ssh-keygen -t rsa -C "[email protected]" //Создаём ssh-ключ на локальной машине, если не был создан ранее

Далее жмем несколько раз “Enter” и получаем вот такое сообщение в консоли.

Далее копируем открытый ssh-ключ в буфер обмена. Команда для копирования вводится в зависимости от Вашей OS.

Для Mac

pbcopy < ~/. ssh/id_rsa.pub

Для Linux (Ubuntu)

cat ~/.ssh/id_rsa.pub

Для Windows (Git Bash)

clip < ~/.ssh/id_rsa.pub

Как ввести SSH ключ на стороне Git’a

Входим в свой аккаунт на Git’e, далее наводим курсор мышки на свою аватарку и жмем “Settings”:

Теперь жмем на вкладку “SSH and GPG keys”:

Далее нажимаем кнопку “New SSH Key”. Указываем имя и вставляем ключ в поле Key. Нажимаем Add Key.

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

Теперь на сайте github.com создадим новый репозиторий, если это новый проект.
Теперь перейдём в папку с проектом на локальной машине и дадим команду:

git init //Инициализация git-репозитория
git add * //Добавим существующие файлы для отслеживания изменений в них
touch .gitignore //Создадим файл, куда будем заносить файлы, которые не требуется отслеживать
git remote add origin [email protected]:yourname/yourproject.git //Слинкуем удалённый репозиторий как origin
git pull origin master //Скачиваем последний правки с удалённого репозитория
git push --all //Отправляем новые правки на сервер

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

Покажу на примере Windows.  

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

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

Клонирование репозитория с помощью командной строки

  1. На GitHub перейдите на главную страницу репозитория.

    Примечание. Если хранилище пустое, вы можете вручную скопировать URL-адрес страницы хранилища из браузера и перейти к шагу 4.

  2. Под именем хранилища нажмите Клонировать или загрузить .

  3. Чтобы клонировать репозиторий с использованием HTTPS, в разделе «Клонировать с HTTPS» нажмите . Чтобы клонировать репозиторий с использованием ключа SSH, включая сертификат, выданный центром сертификации SSH вашей организации, нажмите « Использовать SSH» , затем нажмите .

  4. Откройте Git Bash. TerminalTerminal

  5. Измените текущий рабочий каталог на место, где вы хотите сделать клонированный каталог.

  6. Введите,git clone а затем вставьте URL-адрес, скопированный на шаге 2.

    $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

  7. Нажмите Enter. Ваш местный клон будет создан.

    $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
> Cloning into `Spoon-Knife`...
> remote: Counting objects: 10, done.
> remote: Compressing objects: 100% (8/8), done.
> remove: Total 10 (delta 1), reused 10 (delta 1)
> Unpacking objects: 100% (10/10), done.

Клонирование репозитория в GitHub Desktop

  1. На GitHub перейдите на главную страницу репозитория.
  2. Под своим именем репозитория нажмите, чтобы клонировать свой репозиторий в Desktop. Следуйте инструкциям в GitHub Desktop, чтобы завершить клонирование. Для получения дополнительной информации см. « Клонирование хранилища из GitHub в GitHub Desktop ».

GIT: Инструкция-шпаргалка для начинающих

GIT: Инструкция-шпаргалка для начинающих

Ссылка на оригинал

Время создания: 07.06.2012 23:37

Раздел: Компьютер — Программирование — Системы контроля версий (VCS) — Git

Запись: xintrea/mytetra_syncro/master/base/1339097829h0xmeapk1u/text.html на raw.github.com

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

Почему Git

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

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

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

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

Более подробно можно прочитать http://habrahabr.ru/blogs/Git/104198/

Общие сведения о Git

Подробно о работе с Git, что это такое можно прочитать в Git Book по адресу http://book.git-scm.com/

В классических VCS (Version Control System) (CVS, SVN), в рабочей копии хранится текущее состояние репозитория, и базовая копия текущей ревизии. На сервере хранятся все ревизии в виде изменений от предыдущей, либо в виде полных копий каждой ревизии с вычислением разницы по запросу. Все ревизии нумеруются по порядку начиная от первой.
В случае CVS хранятся изменения и нумерая по каждому файлу независимо, в случае SVN, нумеруются изменения репозитория.


Так как SVN хранит только изменения всего репозитория, «ветки» в нем реализуются через специальную организацию файлов в хранилище. Классически, это /trunk/ для последнего кода, /branch/somename/ для веток. Для создания ветки, делается копия /trunk/ в /branch/somename/, над которым уже работает разработчик.
При этом, при каждом коммите, идёт обращение к центральному репозиторию, для сохранения изменения, отрабатывают скрипты на сервере, идет непрерывная нумерация изменений, запрос истории так же требует обращения на сервер и т.д.

Git относится к классу DVCS (Distributed Version Control System). При этом рабочая копия содержит все коммиты, историю, ветки, всё необходимое для ведения разработки без обращения к какому-либо серверу. Для синхронизации изменений между разными копиями репозитория, в нужный момент делается pull чтобы скопировать изменения удалённого репозитория к себе, либо push чтобы скопировать локальные изменения в удалённый репозиторий. В случае с Git, каждый коммит имеет уникальный ID в виде хеша, содержащий в себе все файлы, относящиеся к нему.

Каждый коммит имеет один коммит-родитель, и, возможно, коммит-источник слияния. Таким образом, коммиты представляют собой дерево наборов файлов. «Веткой» является указатель на какой-либо коммит. Таким образом, чтобы создать ветку, нужно просто дать имя какому-либо коммиту. Чтобы слить две ветки, одна из которых начинается с конца другой, можно просто передвинуть указатель второй ветки на новый коммит (это называется Fast-Forward).

Чтобы поддерживать «плоскую» основную ветку (master), используется техника ребейза веток перед слиянием, и слияение без fast-forward’а.

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

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

Подробнее о том, что такое rebase в картиках тут: http://book.git-scm.com/4_rebasing.html

Алгоритм работы над задачей

Стандартный алгоритм работы над какой-либо задачей выглядит так:

  1. Создаётся ветка, основывающаяся на последней копии master ветки. Название новой ветки содержит класс задачи, краткое описание, номер задачи в БТ. Например feature/sessions_add_datetime_filter.5503
  2. Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит.
    Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.
  3. После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка ребейзится относительно последнего мастера, и пушится в центральный репозиторий.
  4. Второй человек, работающий над тем же проектом, делает к себе pull центрального репозитория. Если он уже смотрел – то удаляет свою локальную копию ветки, после чего переключается на указанную ветку. Прочитывает код, проверяет его работоспособность, после чего либо отдаёт на доработку, если там обнаружены проблемы, либо делает еще раз rebase поверх мастера, и слияние ветки с мастером.
  5. После слияния с мастером, ревьюер пушит новый мастер в центральный репозиторий, удаляет у себя локальную ветку задачи, пушит в мастер удаление ветки задачи.
  6. Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master.

Правила ведения чистых коммитов

Все коммиты, которые попадают в центральную ветку, должны следовать следующим правилам:

  1. Автором должен быть прописан разработчик – Имя, Фамилия, рабочий e-mail.
  2. Текст комментария должен содержать краткое описание изменения. Для зарубежных проектов описание обязано быть на английском языке, для проектов российского бранча приемлемо комментировать на русском.
  3. Коммит не должен содержать в себе файлы, не относящиеся к изменениям. Если ваша IDE, OS, какой-то плагин какому-либо софту использующемуся при разработке создают технические файлы, либо добавьте их в .gitignore, либо не добавляйте к коммиту, либо удаляйте перед коммитом.
  4. Коммит не должен добавлять/убирать пустые строки, менять пробелы на табы и наоборот, менять число пробелов и т. п. нигде, кроме случаев, относящихся к сути коммита. То есть при рефакторинге это нормально, но если ваш редактор поменял во всем файлые пробелы на табы или наоборот – меняйте настройки редактора или перед коммитом приводите всё к виду «как было».
  5. Стиль исходного кода и отступов должен совпадать с текстом вокруг. То есть, если всюду в файле используются табы для отступа, не следует вставлять еще один case выровненный пробелами.
  6. Минимизация конфликтов. При добавлении кода следует стараться форматировать код так, чтобы модификация его приводила к минимуму конфликтов при слиянии.

Работа под Windows

Для работы с Git под Windows самое удобное – использовать TortoiseGit. Однако следует знать, что на 2017 год есть более удобный инструмент — SmartGit.

Подготовка к работе

  1. Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
    Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen.
  2. Устанавливается msysGit из проекта http://code.google.com/p/msysgit/
    Выбрать опции при установке «Add “Git Bash here”», «Run Git from the Windows Command Prompt», «Use Windows style line endings», когда спросит – дать путь до plink.exe
  3. Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
    После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика.
  4. С помощью puttygen создаётся пара приватный+публичный ключ.
    Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
    Приватный ключ добавляется в pagent через клик правой кнопкой → add key.

Получение репозитория

В папке, где будут размещаться все рабочие проекты, жмём
Правой кнопкой→TortoiseGit→Clone, вводим адрес центрального репозитория
ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git
В поле «Load Putty Key» выбираем путь до приватного ключа.

Основные используемые функции

При работе используются либо консольные утилиты, аналогично linux, либо графический интерфейс.

  1. Обновление текущей ветки из центрального репозитория:
    В контекстном меню папки с исходниками TortoiseGit->Pull

  2. Отправка текущей ветки в центральный репозиторий:
    В контекстном меню TortoiseGit→Push
    Выбираем в Local сперва master, потом нашу текущую ветку.
    Remote заполняется при этом автоматически.
    Название remote ветки должно быть идентично local
  3. Переключение на некоторую ветку:
    В контекстном меню TortoiseGit→Switch/Checkout
    В меню Branch выбрать remotes/origin/<нужная ветка>
    [v] «Create new branch», название <нужная ветка>, [v] «Track»

  4. Создание новой ветки
    Контекстное меню→TortoiseGit→Create Branch
    В Name в Branch вводим нужное название ветки
    Чтобы ветка базировалась от текущей, в Base On выбираем HEAD
    Чтобы ветка базировалась от мастера, выбираем Branch, в списке master.
    Ставим [v] Switch to new branch чтобы сразу переключиться на ветку.

  5. Удаление веток
    Открываем меню зажав кнопку Shift → TortoiseGit → Browse Reference
    в разделе heads лежат локальные ветки, в разделе remotes\origin удалённые.
    Выбираем нужную ветку, жмём правой кнопкой → Delete Remote Branch
    Для локальной ветки, соответственно, Delete Branch.
  6. Слияние ветки с текущей
    Контекстное меню → TortoiseGit → Merge
    выбираем Branch который нужно слить с текущей веткой
    ставим обязательно галочку «No fast forward», Merge message не трогаем.
  7. Просмотр и сохранение изменений
    Файлы с изменениями помечены красными восклицательными знаками.
    Чтобы посмотреть общую картину изменений,
    Меню→Git Commit -> “ветка”
    Внизу список изменений в репозитории, обязательно нажимать галочку «View patch» и проверять изменения на предмет соответствия Правилам ведения чистых коммитов.

Стандартные процедуры работы

  1. «Начало работы над задачей»
    Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
    Меню → TortoiseGit → Switch/Checkout,
    Branch: master
    Меню → TortoiseGit → Pull
    Меню → TortoiseGit → Create Branch
    Name Branch: название новой ветки
    Base On: HEAD (master)
    [x] Switch to new branch
  2. «Коммит очередного кусочка работы»
    Выполняется после выполнения некого изменения, суть которого целостная.
    Меню → Git commit -> “имя ветки”
    Отметить файлы, только нужные для данного конкретного коммита
    Обязательно щелкнуть на «View Patch», и убедиться
    в соответствии правилам ведения чистых коммита
    В message ввести описание изменения, соответствующее правилам
  3. «Отправка ветки на центральный репозиторий»
    Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
    Меню → TortoiseGit → Push
    Выбираем в Local сперва master, потом нашу текущую ветку.
    Remote заполняется при этом автоматически.
    Название remote ветки должно быть идентично local
    Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
  4. «Ребейз относительно мастера»
    Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
    Меню → Git Sync
    Local branch: master
    Remote branch: master
    Правая стрелочка вниз у первой кнопки (Pull по умолчанию), Fetch
    Меню → TortoiseGit → *Rebase
    Branch: текущая ветка
    UpStream: master
    Если будут конфликты – разобраться с ними через вкладку «Conflict File»
    На выбор, правой кнопкой файла, утилиты
    Edit Conflicts – позволяет по каждому расхождению выбрать
    использовать версию какую блока
    Resolve Conflicts Using
    theirs – использовать версию мастера
    mine – использовать версию текущей ветки
    Open – открыть в редакторе, и исправить вручную
    После исправления сделать Resolve
    После исправления всех конфликтов нажать Commit
    После ребейза нажать Done
  5. «Кратковременное сохранение состояния изменений»
    Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
    Меню → TortoiseGit → Stash Save
    После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
    Меню → TortoiseGit → Stash Pop
    Тем самым восстановив состояние изменения.
  6. «Длительное сохранение состояния изменений»
    Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
    Меню → Git Commit -> “ветка”
    Отмечаем все-все изменения (Select/Deselect All)
    В текст сообщения пишем «Partial commit»
    Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
    Меню → TortoiseGit → Show Log
    Выделяем коммит, который идет в дереве сразу перед «Partial commit»
    Правой кнопкой → Reset <ветка> to this
    Reset type: Mixed
  7. «Ревью ветки»
    Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.
    Меню → TortoiseGit → Switch/Checkout
    Branch: master
    Меню → TortoiseGit → Pull
    Меню → TortoiseGit → Switch/Checkout
    Branch: remotes/origin/нужнаяветка
    [x] Create new branch: нужнаяветка
    [x] Force
    [x] Track
    [x] Override branch if exists
    Меню → TortoiseGit → *Rebase
    Branch: нужнаяветка
    UpStream: master
    Ветка ветка должна быть «up to date» или заребейзится без конфликтов.
    == Анализируем изменения просмотром лога изменений через
    Меню → TortoiseGit → Show log
    и смотрим изменения от master до последнего
    == Смотрим общее изменение относительно мастера
    Меню → TortoiseGit → Diff with previous version
    Version 1: HEAD
    Version 2: master
    == если всё хорошо, делаем
    Меню → TortoiseGit → Switch/Checkout
    Branch: master
    Меню → TortoiseGit → Merge
    From: нужнаяветка
    [x] No fast forward
    Сообщение не редактируем.
    Меню → TortoiseGit → Push
    И удаляем ветки:
    Shift + Меню → TortoiseGit → Browser Reference
    в дереве слева Refs => heads => находим ветку, правой кнопкой, Delete branch
    в дереве слева remotes => origin => находим ветку, правой кнопкой,
    Delete remote branch

Работа под Linux

Подготовка к работе

  1. Устанавливаются системные пакеты ssh-client и git
  2. Создаётся приватный ключ:

    ssh-keygen -t dsa -C «Ivan Petrov <work@mail>»

  3. Настраивается ФИО и Емейл автора:

    git config —global user. name «Ivan Petrov»
    git config —global user.email work@mail»

  4. Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

Получение репозитория

Переходим в директорию для работы, и запускаем

git clone ssh://git@СЕРВЕР:ПОРТ/РЕПОЗИТОРИЙ.git

Основные используемые функции

  1. Обновление текущей ветки из центрального репозитория:

    git pull

  2. Отправка текущей ветки в центральный репозиторий:

    git push origin branchname

  3. Переключение на некоторую ветку:

    git checkout branchname

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

  4. Создание новой ветки, базирующейся на текущей

    git checkout -b branchname

  5. Удаление веток

    git branch -d branchname == удаление локальной уже слитой ветки
    git branch -D branchname == принудительное удаление локальной ветки
    git push origin :branchname == удаление ветки с центрального репозитория

  6. Слияние ветки с текущей

    git merge —no-ff branchname

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

    git status

  8. Просмотреть текущие изменения:

    git diff

  9. Сохранение текущих изменений:

    git add именафайлов == добавить измененные/созданные файлы/директории
    git rm именафайлов == добавить удаление файла/директории
    git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
    git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

Стандартные процедуры работы

  1. «Начало работы над задачей».
    Выполняется перед началом работы над задачей. Дерево должно быть без изменений.

    git checkout master
    git pull
    git checkout -b branchname

  2. «Коммит очередного кусочка работы».
    Выполняется после выполнения некого изменения, суть которого целостная.

    # проверяем, какие файлы изменились к текущему моменту
    # удаляем если что-то попало совсем лишее
    git status

    # смотрим текст изменений, на предмет соответствия
    # правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
    git diff

    # если какие-либо файлы не должны попасть в коммит (например,
    # относятся к другому атомарному изменению.)
    # то помечаем только те файлы, изменения которых нужно сохранить
    git add …
    git rm …

    # сохраняем. -m можно опустить, тогда комментарий через редактор
    git commit -m «Some commit message»

    # если все на текущий момент созданные изменения нужно сохранить, то
    # через git add добавляем новые файлы, а всё остальное сохраняем через
    git commit -a -m «Some commit message»

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

    git push origin branchname

    Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.

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

    git checkout master
    git pull
    git checkout branchname
    git rebase master

    При возникновении конфликтов, нужно:

    (*)
    git status == проверить файлы, для которых есть неразрешенные конфликты.

    Редактируем первый файл с конфликтом: находим в нем «<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> содержит текст из нашей ветки. Нужно на этом месте оставить одну единую версию, содержащую общий код и мастера и нашей ветки

    git add измененный_файл

    перейти на (*)

    После исправления конфликтов во всех файлах, запускаем

    git rebase —continue

    Если конфликты несовместимые с дальнейшим продолжением ребейза

    git rebase —abort == прерывает ребейз и возвращает ветку в исходное

    состояние (до начала ребейза)

    После ребейза обновляем состояние ветки в центральном репозитории

    git push origin branchname -f

  5. «Кратковременное сохранение состояния изменений».
    Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
    git reset HEAD .

    Важно! После такой процедуры сохранения/восстановления, при следующем

    git push origin branchname

    Будет выдано предупреждение о непоследовательном изменении. Чтобы принудительно отправить изменения, следует добавить опцию -f.

    git push -f origin branchname

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

  6. «Ревью ветки».
    Выполняется на чистом дереве, временно сохраните изменения согласно пункта 5, если требуется.

    git checkout master
    git pull
    git branch -D branchname
    git checkout branchname
    git rebase master == ветка обязана наложиться без конфликтов
    git diff master == изучаем разницу от мастера или общим диффом, или
    git log master..HEAD == смотрим какие коммиты были между мастером и текущей веткой

    Если всё хорошо, делаем:

    git checkout master
    git merge —no-ff branchname
    git push origin master
    git push origin :branchname
    git branch -d branchname

Так же в этом разделе:

  • Бесплатные сервиса размещения репозитариев Git
  • Git workflow — Теория
  • Git workflow — Краткое введение по основным инструкциям
  • Git Wizardry
  • Про Git на пальцах (для переходящих с SVN)
  • Git на двоих
  • Ежедневный Git
  • Удачная модель ветвления для Git
  • Синхронизация через GIT
  • Git stash — работа с «карманом» в Git
  • Как посмотреть настройки репозитария Git и как их изменить
  • GIT: Инструкция-шпаргалка для начинающих
  • Как перенести локальный GIT-репозитарий на сервер вместе со всей историей
  • git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
  • git revert — отмена изменений, произведенных в прошлом отдельным коммитом
  • Git — работа с ветками
  • Git: Путь Github. Цикл разработки — Простое объяснение
  • Машина времени в GIT
  • Git Rebase: руководство по использованию
  • Git: просмотр лога (истории) в консоли в виде дерева
  • Git: понимание команды git merge
  • Git: Опции слияния для команд merge и pull — определение стратегии слияния
  • Git: как переключиться на нужный коммит
  • Git: как смержить изменения из experimental в master
  • Git: как посмотреть изменения, внесенные определенным коммитом
  • Git: как посмотреть историю изменения одного файла
  • Git: как вернуть один файл в состояние, которое было в определенном коммите
  • git log — особенности данной команды при навигации по истории через git checkout
  • Git: Как исправить HEAD detached from
  • Git: что делать в состоянии detached head
  • Работа в команде с использованием Git на примере проекта в среде Blender 3D
  • Git: Как внести изменения в последний коммит
  • Как в Git создать новую ветку в условиях, когда что-то уже было изменено после последнего коммита
  • Как в Git залить новую локальную ветку в удаленный репозитарий
  • Git: Как подключить новую ветку с удаленного сервера
  • Git: Как узнать текущую ветку
  • Git: В чем разница между Fetch и Pull?
  • GIT: Как исправить ошибочный комментарий к коммиту или файлы в коммите
  • Как настроить git на использование proxy-сервера
  • Использование Git через HTTP-proxy
  • Настройка работы Git через Proxy-сервер
  • Git через proxy
  • Использование git за прокси с аутентификацией
  • Что делать, если в России заблокирован GitHub — быстрое решение
  • Как в Git смержить изменения до конкретного коммита?
  • Самый удобный визуальный клиент Git под основные платформы — SmartGit
  • Основы системы управления версиями Git для новичков на примере SmartGit
  • Как сделать подключение к репозитарию Git через Socks Proxy в условиях отсутствия DNS
  • Как сделать подключение к репозитарию Git через проксирующее SSH соединение
  • Как работать с незавершенными изменениями в коде? Как их коммитить в Git?
  • Как в Git посмотреть незакоммиченные изменения в текстах исходников?
  • Как поместить на GitHub уже существующий репозитарий
  • Что происходит при откате изменений через git reset —soft
  • Не бойся хардресета! Он твой друг и помощник. (Как пользоваться git reset)
  • Как пометить определенный коммит тегом версии
  • Как в Git удалить файлы из индекса, не удаляя их в рабочей директории
  • Как настроить GIT, чтобы при конфликте слияния он прописывал в файл не только различия, но и «базу» этих различий
  • Git: Разрешение конфликтов объединений
  • Git: Извлечение старой версии файла
  • Git stash: временный отказ от проделанной работы
  • Git: проверка состояния репозитария, поддержание репозитария в рабочем состоянии
  • Как в Git отменить локальные изменения и получить новое состояние из удаленного репозитария
  • Как искать изменения в нужных файлах с помощью интерфейса gitk?
  • Как выбрать одну из версий бинарного файла при возникновнии конфликта слияния?
  • Как в Git посмотреть старый коммит, а потом вернуться обатно к самому последнему коммиту
  • Получение хеша последнего коммита и его даты в Git (для версионирования)
  • Памятка по неочевидным деталям использования Git
  • Как синхронизировать форк на Github с основным репозитарием через веб-интерфейс
  • Как пользоваться GitHUb: форки, ветки, запросы на добавление кода
  • Как отменить (сбросить) еще не закоммиченные изменения в Git
  • Первоначальная настройка имени пользователя и Email в Git-проекте
  • Можно ли принимать изменения через git pull если не закоммичены изменения рабочей директории
  • Как посмотреть какие команды генерирует git gui
  • Как удалить файл в Git-репозитарии с изменением истории

MyTetra Share v. 0.58

русский язык · GitHub Topics · GitHub

Вот 314 публичных репозиториев соответствует этой теме…

ай-навсегда / ru-gpts

Звезда 1,7к

ай-навсегда / ру-далле

Звезда 1,6к

Козиев / чат-бот

Звезда 221

акарнокд / открытый ИГ

Звезда 207

вларин / трансформеры-ру

Звезда 162

Чемблис / Многоязычный_NER

Звезда 146

матюшкин / дс

Звезда 132

матюшкин / уроки

Звезда 120

снейкерс4 / russian_stt_text_normalization

Звезда 106

датакун / русские имена

Звезда 103

Старый Бонарт / Осинт-Ресурсы

Звезда 88

lsfusion-решения / моя компания

Звезда 85

Гекслет / RestApiTutorial.

ru Звезда 80

перевод-банда / документы-следующий

Звезда 73

cpp-ru / идеи

Звезда 71

СОБАКА729 / ruMount-BladeBannerlord

Звезда 57

Старый Бонарт / ML-ресурсы

Звезда 57

авантюра / АРУ

Звезда 51

AlexxNB / svelte3-translation-ru

Звезда 49

алордаш / BotSmartScheduler

Звезда 45

Улучшить эту страницу

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

Курировать эту тему

Добавьте эту тему в свой репозиторий

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

Узнать больше

Использование Git в классе

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

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

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

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

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

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

Используйте клавиатуру

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

Да, командная строка может быть пугающей:

$ здесь можно ввести что угодно

Это компьютерная версия долгого взгляда в бездну — она смотрит в вас. Но учтите: язык интерфейса — это человеческий язык. Просто слова. Это то, что, по правде говоря, более знакомая, чем загадочная иконография, используемая в большинстве интерфейсов. После небольшой практики я предсказываю, что вы и ваши ученики будете постоянно открывать окна терминала и использовать их всякий раз, когда сможете. Есть старая поговорка о графических интерфейсах: они делают простые вещи простыми, а сложные — невозможными. После того, как вы изучили touch , mkdir и cd , посмотрите, какой из них занимает больше времени — GUI или CLI.

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

Все шаги в этой статье будут выполняться с использованием примеров CLI.

Ваш первый репозиторий

Время для Git-эквивалента Привет, мир! Давайте создадим новый каталог для использования в качестве нашего репозитория Git:

mkdir gitdemo
cd gitdemo

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

git init

Вы увидите Initialized пустой репозиторий Git в /path/to/your/repo/.git/ . Что это за . git ? Если вы перечислите все файлы в вашем каталоге ( ls -a ), вы увидите новый скрытый каталог .git/. Именно здесь Git хранит информацию об этом новом репозитории. Время добавить несколько файлов.

touch new.txt
echo "Привет, мир!" > new.txt

У вас будет новый файл new.txt , в котором теперь будет одна строка текста: Привет, мир! Довольно круто, как мы могли сделать это из командной строки, не открывая текстовый редактор, а?

Но это не просто старая папка; это репозиторий Git ! Git отследил, что у нас появился новый файл. Введите следующую команду:

git status

Мы получим следующее:

На мастере ветки
Первоначальная фиксация
Неотслеживаемые файлы:
(используйте "git add...", чтобы включить в то, что будет зафиксировано)
новый.txt
ничего не добавлено для фиксации, но присутствуют неотслеживаемые файлы (используйте «git add» для отслеживания)

Вот пошаговый перевод:

  • У нас может быть несколько версий этой папки, и вы смотрите на одну из них под названием master .
  • Еще не было выполнено ни одной фиксации (сохранения).
  • Я вижу в этой папке несколько файлов, о которых вы мне еще не сказали. Вот они…

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

Итак, прежде чем мы отправим test.txt в АННАЛЫ ИСТОРИИ, мы должны подготовить его.

git add new.txt

После этого ничего не выводится, но запуск git status снова дает:

На мастере ветки
Первоначальная фиксация
Изменения, которые необходимо зафиксировать:
(используйте "git rm --cached ...", чтобы убрать стадию)
новый файл: new.txt

Хорошо, отлично. Теперь Git знает о нашем файле. Пришло время зафиксировать наши изменения в истории Git.

git commit -m «Добавить новый.txt»

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

После команды фиксации вы увидите такой вывод:

[мастер (корневая фиксация) c6c1180]
Добавить new.txt 1 файл изменен, 1 вставка(+)
режим создания 100644 new.txt

Перевод:

  • Наш первый коммит! Также мы находимся на главной ветке. Я сделал уникальный идентификатор для этой фиксации.
  • Вот что изменилось в этой фиксации.
  • Я сделал один файл.

Мы почти закончили! Но большинство ваших коммитов не будут первоначальными, верно? Это будут обновления репозиториев, с которыми вы уже работали. Итак, давайте внесем некоторые изменения.

эхо "Foobar!" >> new. txt

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

На мастере ветки
Изменения, не подготовленные для фиксации:
(используйте "git add...", чтобы обновить то, что будет зафиксировано)
(используйте "git checkout --...", чтобы отменить изменения в рабочем каталоге)
изменено: new.txt
в фиксацию не добавлено никаких изменений (используйте "git add" и/или "git commit -a")

Посмотрите на это! изменено: new.txt . Git видит изменения в нашем файле. Если вам интересно, что именно изменилось в , вы можете запустить git diff new.txt . Это дает что-то вроде:

diff --git a/new.txt b/new.txt
индекс 8ab686e..d8eeaac 100644
--- a/new.txt
+++ b/new.txt @@ -1 +1,2 @@
Привет, мир!
+Фубар!

Обратите внимание на + вокруг добавленной строки. Это кажется разумным изменением, поэтому мы собираемся его зафиксировать. Не забудьте git add new.txt или git add -A , чтобы добавить этот файл или все файлы, соответственно, в промежуточную область. Еще один вызов git commit с соответствующим сообщением фиксации дает нам в общей сложности две фиксации в нашей истории. Идите вперед и посмотрите, что Git отслеживает для вас с помощью git log .

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

Переход на удаленку

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

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

ПРИМЕЧАНИЕ ПО БЕЗОПАСНОСТИ: В сообществе FOSS мы все друзья. И мы все время скачиваем код с других компьютеров. Но то, о чем я собираюсь вас попросить, требует определенного доверия, и я не думаю, что вы должны делать это вслепую. Пожалуйста, не стесняйтесь просматривать этот крошечный репозиторий, чтобы убедиться, что я не пытаюсь заразить вашу машину вредоносным кодом. Или любой код, если на то пошло.

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

git remote add upstream https:// github.com/mttaggart/gitdemo

Нет вывода значит сработало. Теперь мы готовы загрузить (извлечь) и объединить файлы на GitHub с вашим локальным репозиторием. Мы можем сделать оба шага одновременно с помощью git pull или выполнить оба шага по отдельности с помощью git fetch и git merge . Для простоты потянем:

git pull восходящий мастер

Эй, что это за мастер? Не беспокойся; это просто означает, что мы находимся в основной ветке   репозитория, основной ветке.

Думаю, это багажник. В любом случае, вы видите этот вывод:

Слияние по «рекурсивной» стратегии.
README.md | 1 +
1 файл изменен, 1 вставка(+)
создать режим 100644 README.md

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

git log --graph # q завершает работу, j и k прокручивает

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

Если бы вы и я работали вместе над этим репозиторием, а затем внесли некоторые изменения, которые необходимо зафиксировать в нашем общем репозитории GitHub, вы бы просто git push загрузили свои изменения в GitHub, объединив их с тем, что было там ранее .

«Отлично, Таггарт, теперь я могу использовать Git. Как это делает меня лучшим учителем?» Секрет в том, чтобы думать вне кода.

Git-портфолио

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

Git, Git, Git, HTML и Git.

Представьте себе, что учащиеся ведут каталог документов (в идеале в формате Open Document Format или, что еще лучше, в формате HTML), которые они курируют на протяжении всей своей школьной карьеры. Возможно, каждый квартал они принимают какие-то решения о том, какой работой они гордятся больше всего. Они добавляют эти файлы в репозиторий Git, фиксируют и отправляют в удаленное репо. Это не обязательно должен быть GitHub, если вас беспокоит конфиденциальность. Такие проекты, как GitLab, позволяют школам создавать собственные удаленные репозитории Git, не полагаясь на третьи стороны.

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

Информатика с Git

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

Вот как я это сделал:

1. Создайте исходный репозиторий

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

2. Настройка учетных записей учащихся

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

3. Разветвить вышестоящий репозиторий

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

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

4. Клонировать/извлекать студенческие репозитории

git clone захватывает удаленный репозиторий и загружает локальную копию на ваш компьютер вместе с историей коммитов репозитория. У меня есть папка, в которой я git clone d все репозитории моих учеников. Затем, используя небольшой Bash-скрипт, который я написал, я извлекаю все репозитории как один раз, создавая объединенный файл журнала двух последних коммитов каждого студента. Их коммиты говорят мне, над чем они работали с тех пор, как я последний раз проверял, поэтому я знаю, что нужно вернуться и просмотреть старые уроки, если они улучшили свои решения.

No related posts.