Работа с распределенной системой контроля версий git на примере github

Создаем свой первый проект и выкладываем на GitHub

Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).

Перед началом предлагаю зарегистрироваться на GitHub.

Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.

После открываем VS Code .

1. Установите себе дополнительно анализаторы кода для JavaScript и PHP

2. Откройте вашу папку, которую создали ранее

После этого у вас появится вот такой интерфейс

1. Здесь будут располагаться все файлы вашего проекта

2. Здесь можно работать с Git-ом

3. Кнопка для создания нового файла

4. Кнопка для создания новой папки

Давайте теперь перейдем во вкладу для работы с Git-ом.

Откроется вот такое окно:

1. Кнопка для публикации нашего проекта на GitHub

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

После того, как выбрали «Опубликовать на GitHub публичный репозиторий» (пункт 2), программа предложит вам выбрать файлы, которые будут входить в первый commit. Проставляем галочки у всех файлов, если не проставлены и жмем . Вас перекинет на сайт GitHub, где нужно будет подтвердить вход в аккаунт.

Вы создали и опубликовали репозиторий на GitHub.

Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать (Windows) или (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.

Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:

1. Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки

2. Добавляем наш файл для будущего commit

3. Пишем комментарий

4. Создаем commit

5. Отправляем наш commit в GitHub

Поздравляю, вы научились создавать commit и отправлять его в GitHub!

Итог

Это первая вводная статья по утилите Git. Здесь мы рассмотрели:

• Как его устанавливать

• Как его настраивать

• Как инициализировать репозиторий и создать commit через консоль

• Как на примере VS Code, опубликовать свой код на GitHub

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

P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.

Получаем доступ к репозиторию

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

1. Регистрация на GitHub’e.

Профиль на GitHub.com

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык – Git Bush – вот с помощью него и запускаем консоль.

1. Набираем в консоли следующую команду
2. На экране появится запрос “Enter file in which to save the key”. Пока оставим значение по умолчанию. Жмем Enter.
3. Нас попросят ввести пароль. Эту часть тоже пропускаем – впоследствии пароль можно будет установить, а пока – учимся. Жмем опять Enter.
4. Сгенерируются два файла один из которых – публичный ключ для доступа.

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

Заходим в директорию, открываем с помощью “Блокнота” файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
2. Выбираем пункт “SSH Public Keys”
3. Жмем ссылку “Add another public key”

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key – поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

Ветвление

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

$ git branch

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

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

$ git checkout -b new-features

Мы только что создали новую ветку под названием «new-features» и переключились на эту ветку. Если мы запустим ветку Git, вы увидите следующее:

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

$ git add .
$ git commit -m "JavaScript Library"

В данный момент это файлы проекта в нашем каталоге:

Теперь, если мы вернемся к нашей основной ветке.

$ git checkout master

Если вы посмотрите каталог нашего проекта, то увидите, что папка JavaScript отсутствует. Это потому, что мы посвятили все это ветке новых функций. В этом прелесть ветвления: все, что вы делаете в одной ветке, не будет видно в других ветвях.

Системы контроля версий

Древняя система контроля версий

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с «научкой» становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

Такой способ совершенно не приемлем* в мире разработки, особенно, если над проектом трудится много человек одновременно. И вот почему:

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

Современная система контроля версий

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

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

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

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

Применение fixup для сжатия коммитов

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

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

Обратите внимание: хэш коммита также изменился, а сообщение о коммите берется из “основного” коммита, с которым были сжаты другие два

Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою «копию» проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

Применяйте pull только как fast-forward

На всякий случай, напоминаю, что по умолчанию делает (выкачивание ветки с удалённого репозитория) и (слияние локальной и удалённой веток), а — это режим слияния, когда нет никаких изменений в локальной ветке и происходит «перемотка» её на последний коммит из удалённой. Если изменения есть, то происходит классический мерж с ручным разрешением конфликтов и мерж-коммитом.

Некоторые предпочитают использовать , но не всегда это возможно, например, когда вы локально смержили другую ветку из в и перед пушем делаете (надеюсь, не надо напоминать, чем в данном случае может грозить ).

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

Что мы получаем?

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

Step 9: Merge a PR

Go ahead and click the green ‘Merge pull request’ button. This will merge your changes into the primary branch.

When you’re done, I recommend deleting your branch (too many branches can become messy), so hit that grey ‘Delete branch’ button as well.

You can double check that your commits were merged by clicking on the ‘Commits’ link on the first page of your new repo.

This will show you a list of all the commits in that branch. You can see the one I just merged right up top (Merge pull request #1).

You can also see the hash code of the commit on the right hand side. A hash code is a unique identifier for that specific commit. It’s useful for referring to specific commits and when undoing changes (use the git revert <hash code number> command to backtrack).

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
3. Просим клиента внести изменённые файлы в репозиторий. Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
4. После коммита версия вашего локального репозитория изменилась.
5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

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

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

Установка Git

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

Примечание

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

Установка в Linux

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

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

Чтобы воспользоваться дополнительными возможностями, посмотрите инструкцию по установке для нескольких различных разновидностей Unix на сайте Git https://git-scm.com/download/linux.

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

Существует несколько способов установки Git на Mac.
Самый простой — установить Xcode Command Line Tools.
В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив ‘git’ в терминале.

Если Git не установлен, вам будет предложено его установить.

Если Вы хотите получить более актуальную версию, то можете воспользоваться бинарным установщиком.
Установщик Git для OS X доступен для скачивания с сайта Git https://git-scm.com/download/mac.

Рисунок 7. OS X инсталлятор Git

Установка в Windows

Для установки Git в Windows также имеется несколько способов.
Официальная сборка доступна для скачивания на официальном сайте Git.
Просто перейдите на страницу https://git-scm.com/download/win, и загрузка запустится автоматически.
Обратите внимание, что это отдельный проект, называемый Git для Windows; для получения дополнительной информации о нём перейдите на https://gitforwindows.org. Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом

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

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

Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat, and libiconv.
Например, если в вашей системе используется (Fedora) или (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:

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

Примечание

Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны для корректной установки пакета

Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет :

Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет , который уже установлен в системах на базе Debian:

К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:

Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест:
с сайта Kernel.org https://www.kernel.org/pub/software/scm/git, или зеркала на сайте GitHub https://github.com/git/git/releases.
Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.

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

После этого вы можете получать обновления Git посредством самого Git:

prev | next

Что такое 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.

Как настроить правильную техподдержку (helpdesk, service desk на коленке)

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

В статье я расскажу, как оказываем поддержку мы, как выстроили этот бизнес-процесс, что контролируем и на что обращаем внимание в работе

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

Мне уже удобно с терминалом (Вариант 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

Step 4: Create a commit

It’s time to create your first commit!

Run the command

The message at the end of the commit should be something related to what the commit contains — maybe it’s a new feature, maybe it’s a bug fix, maybe it’s just fixing a typo. Don’t put a message like «asdfadsf» or «foobar». That makes the other people who see your commit sad. Very, very, sad. Commits live forever in a repository (technically you can delete them if you really, really need to but it’s messy), so if you leave a clear explanation of your changes it can be extremely helpful for future programmers (perhaps future you!) who are trying to figure out why some change was made years later.

10 шагов для работы с проектом

Создаем локальную копию вашего проекта

Для github project_url можно найти нажав зеленую кнопку «Clone or download» на странице проекта.
Обновляем локальную копию — подгружаем изменения, которые внесли другие участники в эту ветку

Узнаем название вашей текущей ветки, смотрим какие файлы были изменены локально, смотрим какие комиты (commits) вы не отправили на общий сервер

Выкидываем все ваши локальные изменения

Применять осторожно, можно выстрелить в ногу.

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

Примечание: ветка создается от той ветки в которой вы в настоящий момент находитесь (см. предыдущий пункт), поэтому как правило надо сначала переключиться в ветку master. Если есть измененный файлы, то ничего страшного — они никуда не пропадут.
Переключаемся в ветку master:

Создаем новую ветку:

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

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

После внесения локальных изменений их надо так сказать «закомитить». Надо отметить, что git вносит изменения (создает новый commit) в вашу локальную версию, на сервер ничего не отправляет. Для отправки на сервер есть другая команда. Лично я комичу из IDE. Но можно и руками.
Сообщаем git какие файлы мы хотим закомитить:
Или сразу все файлы
Коммитим:

Отправляем файлы в репозиторий на сервере

Примечание — git ругается, что не знает куда отправлять — смотри примечание к пункту 2.
Отправляем изменения на просмотр (review) другим участникам. Это UI штука, к git отношения не имеет. В github, например, надо просто в UI перейти в свою ветку и создать Pull request (PR)
Сливаем ваши изменения в основную ветку. Тут есть несколько вариантов. По умолчанию git просто встроит все ваши комиты в общую ветку. То есть все увидят ваши нелепые попытки исправить несобирающийся билд, падающие тесты и просто вечерние комиты, которые вы сделали, чтобы не потерять результаты кропотливого дневного труда. Это хорошо, если вы эксбиционист, но как правило жедательно все комиты собрать в один и встроить в общую ветку именно одним комитом (т.н. squash commit) — так другим будет легче разобраться что же вы сделали перед тем, как что-то пошло не так и откатить ваши изменения. Поэтому желательно делать squash:
В интерфейсе github есть зеленая кнопочка «squash & commit». Через UI переходим в свою ветку, создаем Pull request (PR), а потом в интерфейсе PR выбираем и жмете «squash & commit».

Переходим в основную ветку (master)

, обновляемся

, делаем squash commit. Все изменения, из нашей ветки появятся как локальные, но уже в основной ветке. Смотрим что мы наваяли. Посмотреть изменения — пункт 3. Комитим — пункт 8, отправляем на сервер — пункт 9. Можно делать squash commit не в основную ветку, а завести новую, сделать в нее squash commit и из нее сделать merge в основную (смотри следующий пункт).

Ваши комиты в этом случае не склеятся в один. Переходим в основную ветку (master)

, обновляемся

, делаем обычный commit

, отправляем на сервер — пункт 9.

Можно сделать rebase ветки и, например, склеить все ваши комиты в один.

Install Git on Linux

Debian / Ubuntu (apt-get)

Git packages are available via apt:

1. From your shell, install Git using apt-get:

2. Verify the installation was successful by typing :

Fedora (dnf/yum)

Git packages are available via both yum and dnf:

1. From your shell, install Git using dnf (or yum, on older versions of Fedora):

   or

2. Verify the installation was successful by typing :

Build Git from source on Linux

Debian / Ubuntu

Git requires the several dependencies to build on Linux. These are available via apt:

1. From your shell, install the necessary dependencies using apt-get:

2. Clone the Git source (or if you don’t yet have a version of Git installed, download and extract it):

3. To build Git and install it under , run :

Fedora

Git requires the several dependencies to build on Linux. These are available via both yum and dnf:

1. From your shell, install the necessary build dependencies using dnf (or yum, on older versions of Fedora):

   or using yum. For yum, you may need to install the Extra Packages for Enterprise Linux (EPEL) repository first:

2. Symlink docbook2X to the filename that the Git build expects:

3. Clone the Git source (or if you don’t yet have a version of Git installed, download and extract it):

4. To build Git and install it under , run :

Git — это распределённая система версий

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

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

Из-за удобства и гибкости распределённая система версий Git считается современным форматом. Это стандарт для большинства ИТ-команд.

Коммиты

Основой истории версий являются коммиты. Для работы с ними используют git commit — эта команда откроет текстовый редактор для ввода сообщения коммита. Кроме того, она принимает следующие аргументы:
• -m — позволяет написать сообщение, не открывая редактор, то есть вместе с командой;
• -a — служит для переноса всех отслеживаемых файлов в область подготовленных файлов и включения их в коммит (даёт возможность перед коммитом пропустить git add);
• —amend — заменяет последний коммит новым изменённым коммитом. Это бывает полезно, когда вы неправильно наберёте сообщение последнего коммита либо забудете включить в него нужные файлы.

Ряд советов по коммитам:
— коммитьте часто;
— одно изменение — один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю);
— комментируя сообщение о коммите, логически дополняйте фразу this commit will ___ и не используйте более 50 символов.

Применение сжатия при слиянии ветвей

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

Давайте рассмотрим следующую команду:

git merge --squash target_branch_name

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

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

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

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

$ cd path/to/project

Запустите следующую команду, чтобы создать репозиторий git:

$ git init

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

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

$ git status

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

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

$ git add index.html style.css

Если вы предпочитаете отслеживать все ваши файлы в рабочем каталоге, просто введите:

$ git add .

Эта команда добавит все ваши файлы в область подготовки Git.

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

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

$ git commit -m "Initial Commit"