Работа с git для начинающих: Git за полчаса: руководство для начинающих

Содержание

Git для новичков (часть 1) / Хабр

Часть 2

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

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

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

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

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

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

Как работает

Если посмотреть на картинку, то становиться чуть проще с пониманием. Каждый кружок, это commit. Стрелочки показывают направление, из какого commit сделан следующий. Например C3 сделан из С2 и т. д. Все эти commit находятся в ветке под названием main. Это основная ветка, чаще всего ее называют master . Прямоугольник main* показывает в каком commit мы сейчас находимся, проще говоря указатель.

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

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

Установка

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

Но для начала, все же установим сам Git.

Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:

#Если установлен Homebrew
brew install git

#Если нет, то вводим эту команду. 
git --version
#После этого появится окно, где предложит установить Command Line Tools (CLT).
#Соглашаемся и ждем установки. Вместе с CLT установиться и git

# Debian или Ubuntu
sudo apt install git

# CentOS
sudo yum install git

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

#Установим имя для вашего пользователя
#Вместо <ваше_имя> можно ввести, например, Grisha_Popov
#Кавычки оставляем
git config --global user. name "<ваше_имя>"

#Теперь установим email. Принцип тот же.
git config --global user.email "<адрес_почты@email.com>"

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

Теперь вы готовы к работе с Git локально на компьютере.

Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.

#Для Linux и MacOS путь может выглядеть так /Users/UserName/Desktop/MyProject
#Для Windows например С://MyProject
cd <путь_к_вашему_проекту>

#Инициализация/создание репозитория
git init

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

#Добавим все файлы проекта в нам будующий commit
git add .
#Или так
git add --all

#Если хотим добавить конкретный файл то можно так
git add <имя_файла> 

#Теперь создаем commit. Обязательно указываем комментарий.
#И не забываем про кавычки
git commit -m "<комментарий>"

Отлично.

Вы создали свой первый репозиторий и заполнили его первым commit.

Процесс работы с Git

Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:

Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код

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

Визуальный интерфейс

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

Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:

Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.

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

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

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

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

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

Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее

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

Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки

Если ваш проект пустой, как у меня, то создайте новый файл и назовите его index.html . После этого откроется окно редактирование этого файла. Напишите в нем ! и нажмите кнопку Tab . Автоматически должен сгенерироваться скелет пустой HTML страницы. Не забудьте нажать ctrl+s чтобы файл сохранился.

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

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

Кнопка для публикации нашего проекта на GitHub
После нажатия на кнопку 1 , появится всплывающее окно. Нужно выбрать второй вариант или там где присутствует фраза ...public repository

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

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

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

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

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

Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Пишем комментарий
Создаем commit
Отправляем наш commit в GitHub

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

Итог

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

Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub

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

git help # справка по всем командам
git clone
git status
git branch
git checkout
git merge
git remote
git fetch
git push
git pull

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

https://learngitbranching.js.org/

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

Знакомство с Git и GitHub: руководство для начинающих | by Olga Sayfudinova | NOP::Nuances of Programming

Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

…а, может, вам просто захотелось поучаствовать в своем первом open-source проекте?

Тогда эта статья специально для вас!

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

Прочитав данную статью вы научитесь клонировать существующий репозиторий, создавать ветки, вносить изменения и отправлять запросы на изменения. Параллельно освоите работу в терминале, терминальные команды и редактирование файла Markdown (.md).

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте — Стене на GitHub.

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

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

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

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

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

Если в статье вы видите команду с угловыми скобками: < > , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.
Пример: git add <имя_файла>. Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py.

Для начала необходимо запомнить следующие терминальные команды:

git clone
git status
git add
git commit -m “ “
git push

Затем к ним добавим еще вот эти:

git init
git branch
git merge
git checkout

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

Не лишней будет и вот такая команда:

git help

О ней мы также поговорим ниже.

(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal).

Шаг 1: Регистрация и установка

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

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

git config — global user.name “<ваше_имя>”

замените <ваше_имя> на свое имя в кавычках. Можете написать все, что угодно. Если хотите задать имя только для одного репозитория, то удалите из команды слово global.

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

git config — global user.email “<адрес_почты@email.com>”

При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.

Теперь вы готовы к работе с Git на локальном компьютере.

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

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

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

git init

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

git init

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

cd new_project
git init

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

git add <имя_первого_файла>

или добавьте сразу все файлы через:

git add .

Создать коммит с этими изменениями можно через команду:

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

Если изменения вас устраивают, напишите:

git push

и отправьте эти изменения в репозиторий. Проверить, есть ли изменения для отправки, можно в любое время по команде:

git status

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

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

или

git add — all

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master.

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

Допустим, вы хотите создать новый репозиторий. Это место, где будет «жить » ваш проект. Если вы не хотите создавать новый репозиторий, то можете склонировать уже существующий. Именно так вы копируете чужой проект или берете нужную вам информацию для работы/учебы. Мы еще к этому вернемся, но чуть позже.

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

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

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Новый репозиторийСоздание нового репозитория

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

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

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

Для начала перейдите в ваш репозиторий.
Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
Нажмите кнопку Commit changes.

Изменение файла на GitHubПодготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request. Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

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

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

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

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

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

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

cd Desktop

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

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

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

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd. Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop. Либо напечатайте cd Desktop. Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.
Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop, вам потребуется выбрать нужного пользователя через команду cd <пользователь> (замените <пользователь> на нужное вам имя). Затем снова напечатайте ls, чтобы увидеть весь список. И вот теперь, увидев в списке Desktop, смело печатайте cd Desktop. Сейчас уже можно выполнять git clone!
Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

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

Совсем не обязательно создавать репозиторий на Рабочем столе. Клонировать можно в любое место на компьютере. Команду git clone можно выполнять и сразу после открытия терминала. Однако, если вы не очень любите копаться в папках на компьютере, то неплохо будет разместить проект на виду, то есть на Рабочем столе…

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

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

git status
git add
git commit -m “ “
git push

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

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

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

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

git status

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

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

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

git add — all

или даже:

git add .

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

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

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

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

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

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

git push

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

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

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

руководство для начинающих. Часть 1

Часть 1, Часть 2

…а, может, вам просто захотелось поучаствовать в своем первом open-source проекте?

Тогда эта статья специально для вас!

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

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом

open-source проекте — Стене на GitHub.

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

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

Если в статье вы видите команду с угловыми скобками: < > , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.

Пример: git add <имя_файла>. Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py.

Для начала необходимо запомнить следующие терминальные команды:

git clone
git status
git add
git commit -m “ “
git push

Затем к ним добавим еще вот эти:

git init
git branch
git merge
git checkout

Не лишней будет и вот такая команда:

git help

О ней мы также поговорим ниже.

Шаг 1: Регистрация и установка

git config — global user.name “<ваше_имя>”

git config — global user.email “<адрес_почты@email.com>”

Теперь вы готовы к работе с Git на локальном компьютере.

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index

или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

git init

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

git init

Допустим, в вашем проекте есть папка new_project. Вы можете перейти в нее из окна терминала и добавить локальный репозиторий.

Это делается через следующую команду:

cd new_project
git init

git add <имя_первого_файла>

или добавьте сразу все файлы через:

git add .

Создать коммит с этими изменениями можно через команду:

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

Если изменения вас устраивают, напишите:

git push

git status

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

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

или

git add — all

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вариант 2. Я вообще ничего не знаю

Ну что ж, приступим к делу!

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.

Новый репозиторий Создание нового репозитория

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

Для начала перейдите в ваш репозиторий.
Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
Нажмите кнопку Commit changes.

Изменение файла на GitHub Подготовка коммита с изменениями

Как вы видите — ничего сложного!

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

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

cd Desktop

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

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

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

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd. Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop. Либо напечатайте cd Desktop. Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop, вам потребуется выбрать нужного пользователя через команду cd <пользователь> (замените <пользователь> на нужное вам имя). Затем снова напечатайте ls, чтобы увидеть весь список. И вот теперь, увидев в списке Desktop, смело печатайте cd Desktop. Сейчас уже можно выполнять git clone!

Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

Совсем не обязательно создавать репозиторий на Рабочем столе. Клонировать можно в любое место на компьютере. Команду git clone можно выполнять и сразу после открытия терминала. Однако, если вы не очень любите копаться в папках на компьютере, то неплохо будет разместить проект на виду, то есть на Рабочем столе…

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

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

git status
git add
git commit -m “ “
git push

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

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

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

git status

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

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

git add — all

или даже:

git add .

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

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

git push

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

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

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]" 
git config --global core.editor nano 
git config --global merge.tool vimdiff 
git config --list

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

ssh-keygen -t rsa -C "[email protected]"

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

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

Для Mac

pbcopy < ~/.ssh/id_rsa.pub

Для Linux (Ubuntu)

Для Windows (Git Bash)

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

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

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

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

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

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

git init 
git add * 
touch .gitignore 
git remote add origin [email protected]:yourname/yourproject.git 
git pull origin master 
git push --all

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

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

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

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

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

На GitHub перейдите на главную страницу репозитория.
Примечание. Если хранилище пустое, вы можете вручную скопировать URL-адрес страницы хранилища из браузера и перейти к шагу 4.
Под именем хранилища нажмите Клонировать или загрузить .
Чтобы клонировать репозиторий с использованием HTTPS, в разделе «Клонировать с HTTPS» нажмите . Чтобы клонировать репозиторий с использованием ключа SSH, включая сертификат, выданный центром сертификации SSH вашей организации, нажмите « Использовать SSH» , затем нажмите .
Откройте Git Bash. TerminalTerminal
Измените текущий рабочий каталог на место, где вы хотите сделать клонированный каталог.
Введите,git clone а затем вставьте URL-адрес, скопированный на шаге 2.

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

$ git clone https:
> 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

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

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

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

Полезные ссылки:

Официальный сайт GitHub;
Синтаксис Markdown.

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

Как подключиться к удаленному репозитарию?

Для загрузки данных в удаленный репозитарию сначала нужно к нему подключиться. В нашем примере мы используем адрес https://github.com/tutorialzine/awesome-project, однако пользователь может создать собственный удаленный репозитарий на GitHub, BitBucket или другом подобном сервисе. Это занимает некоторое время, однако в дальнейшем полностью себя оправдывает, тем более, что подобные службы имеют пошаговые инструкции для правильно выполнения нужных действий.

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

# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git

Первая строка напоминает нам, что URI репозитария, который приведен в примере, нужно изменить на свой.

Иногда бывает так, что проект имеет несколько удаленных репозитариев – в таком случае каждому из них присваивается собственное имя. Главный репозитарий принято называть origin.

Как отправить изменения в удаленный репозитарий?

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

Отправка коммита осуществляется с помощью команды push, которая имеет два параметра — имя удаленного репозитория (в нашем случае origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master

Если мы все сделали правильно, то отправленный файл hello. txt на удаленном сервере мы можем увидеть с помощью браузера. Важный момент – некоторые сервисы для отправки изменений могут требовать дополнительной аутентификации.

Как клонировать удаленный репозитарий?

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

$ git clone https://github.com/tutorialzine/awesome-project.git

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

Как запросить изменения с удаленного репозитария?

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

$ git pull origin master
From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.

Она скачивает новые изменения. Так как мы ничего нового не вносили с тех пор, как клонировали проект, изменений, доступных к скачиванию, нет.

Установка и базовая настройка git. Урок 1

Урок, в котором мы установим git и посмотрим его базовые настройки

Видеоурок. Часть 1. Практика. Установка и настройка git

Видеоурок. Часть 2

Система подсказок и помощи Git
Локальные настройки
Почему первые 2 урока работаем в терминале
Почему уроки в Windows
Чем git bash отличается от стандартной командной строки
Какие утилиты есть кроме git bash
Что еще интересного есть на git-scm.com

Конспект урока

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

Как установить git

Дистрибутивы и инструкции здесь — https://git-scm.com/downloads

В MacOS и Windows ставится через стандартные установщики, в Linux — командой в терминале. Например, если работаете в Debian/Ubuntu/Mint, то


    sudo apt install git

Linux или MacOS

Git прекрасно работает в этих ОС и его функционал доступен из терминала (командной строки)

Windows

Git для Windows включает в себя саму утилиту git и инструменты с графическим интерфейсом. Но есть особенность — при работе в командной строке могут возникнуть проблемы с кириллицей, поэтому мы будем все делать на английском.

Графические инструменты Windows мы рассматривать не будем. Вместо них воспользуемся популярной IDE от JetBrains — PhpStorm.

Почему в уроках Windows

По одной причине — удобство записи видеоуроков. А так я предпочитаю работать в Linux Mint.

Командная строка

В Linux и Mac запускаем команды git из стандартного терминала. В Windows будем использовать утилиту git bash, которая поставляется вместе с установщиком git под Windows. Мы будем работать и в терминале, и в PhpStorm, но некоторые вещи проще делать именно в терминале.

Первые 2 урока (установка и репозитории) мы делаем только в терминале, потому что команд мало и они простые.

Базовая настройка git

Проверим корректность установки git, набрав в командной строке


    $ git --version 
    git version 2.7.4

Глобальные настройки git задаются командой


    git config --global parameter "value"

Для начала нас интересуют только 2 настройки: имя и почта, под которыми нас будут видеть сам git и наши коллеги


    git config --global user.name "Aleksandr Shestakov"
    git config --global user.email "[email protected]"

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


    $ git config --list
    user.name=Aleksandr Shestakov
    [email protected]

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

Дружелюбность git

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

git —help — общая документация по git
git log —help — документация по конкретной команде (в нашем случае log)
Опечатались — git подскажет правильную команду
После выполнения команд — краткий отчет, что было сделано
git подсказывает, что делать дальше

Конечно, все подсказки на английском.

Что могу посоветовать

Работать в Linux или MacOS. В Windows вполне можно работать с git, но иногда бывают проблемы с кириллицей. К тому же я не знаю ни одного программиста, кто ушел с Windows и разочаровался в этом
На первых порах работать с git в графическом интерфейсе PhpStorm, но пробовать и постепенно переходить на командную строку. Работа в терминале поможет лучше понять, как устроен git.
Присмотреться к другим оболочкам, например, zsh
Не заморачиваться с настройками git config. Базовые мы задали, остальные изучатся по мере необходимости
Посмотреть на git-scm.com/downloads/guis, там много интересных графических утилит для работы с Git. Но попозже :-)

Еще раз ссылка на загрузку git — https://git-scm.com/downloads

На этом все. В следующем уроке мы узнаем, что такое репозиторий git, зачем нужны ssh-ключи, а также научимся создавать и клонировать репозитории.

Спасибо за внимание и до встречи!

Все уроки курса

Вводный урок
1. Установка и базовая настройка git
2. Создание и клонирование репозитория git
3. Делаем первые изменения, git status и git diff
4. Коммиты и история коммитов, git commit, git log и git show
5. Подробнее об истории коммитов. Путешествие по истории
6. Работа с сервером, git push и git pull
7. Ветки — главная фишка git, git branch и git checkout
8. Работа с ветками на сервере, git fetch
9. Слияния или мерджи веток, git merge
10. Конфликты и их разрешение
Платная часть курса. Презентация
* 11. Работа с gitignore и git exclude
* 12. Буфер обмена git, git stash
* 13. Копирование коммитов, git cherry-pick
* 14. Отмена и редактирование последнего коммита
* 15. Отмена произвольного коммита, git revert
16. Склеивание коммитов, git rebase —interactive и git reflog
* 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
* 18. Работа с git rebase. Отличия от merge
* 19. Что такое git push —force и как с ним работать
* 20. Ищем баги с помощью git, git bisect
* 21. Как и зачем работать с тегами git
* 22. Процессы: github flow и git flow
* 23. Псевдонимы в git
24. Мердж-реквесты
* 25. Форки

* платные уроки

список обновляется…

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

Работа с 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

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

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

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

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

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

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

Работа под Windows

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

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

Устанавливается putty со страницы http://www.chiark.greenend.org.uk/~sgtatham/putty/
Лучше всего ставить полный пакет, со всеми программами. По надобятся как минимум plink, puttygen.
Устанавливается 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
Устанавливается TortoiseGit из проекта http://code.google.com/p/tortoisegit/
После установки зайти в TortoiseGit → Settings → Git → Config, убедиться что путь до msysgit задан, и что опции AutoCRLF и SafeCRLF установлены, настроены имя, фамилия, email разработчика.
С помощью puttygen создаётся пара приватный+публичный ключ.
Публичный ключ высылается админам для добавления в доступы репозиториев и серверов.
Приватный ключ добавляется в pagent через клик правой кнопкой → add key.

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

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

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

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

Обновление текущей ветки из центрального репозитория:
В контекстном меню папки с исходниками TortoiseGit->Pull
Отправка текущей ветки в центральный репозиторий:
В контекстном меню TortoiseGit→Push
Выбираем в Local сперва master, потом нашу текущую ветку.
Remote заполняется при этом автоматически.
Название remote ветки должно быть идентично local
Переключение на некоторую ветку:
В контекстном меню TortoiseGit→Switch/Checkout
В меню Branch выбрать remotes/origin/<нужная ветка>
[v] «Create new branch», название <нужная ветка>, [v] «Track»
Создание новой ветки
Контекстное меню→TortoiseGit→Create Branch
В Name в Branch вводим нужное название ветки
Чтобы ветка базировалась от текущей, в Base On выбираем HEAD
Чтобы ветка базировалась от мастера, выбираем Branch, в списке master.
Ставим [v] Switch to new branch чтобы сразу переключиться на ветку.
Удаление веток
Открываем меню зажав кнопку Shift → TortoiseGit → Browse Reference
в разделе heads лежат локальные ветки, в разделе remotes\origin удалённые.
Выбираем нужную ветку, жмём правой кнопкой → Delete Remote Branch
Для локальной ветки, соответственно, Delete Branch.
Слияние ветки с текущей
Контекстное меню → TortoiseGit → Merge
выбираем Branch который нужно слить с текущей веткой
ставим обязательно галочку «No fast forward», Merge message не трогаем.
Просмотр и сохранение изменений
Файлы с изменениями помечены красными восклицательными знаками.
Чтобы посмотреть общую картину изменений,
Меню→Git Commit -> “ветка”
Внизу список изменений в репозитории, обязательно нажимать галочку «View patch» и проверять изменения на предмет соответствия Правилам ведения чистых коммитов.

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

«Начало работы над задачей»
Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
Меню → TortoiseGit → Switch/Checkout,
Branch: master
Меню → TortoiseGit → Pull
Меню → TortoiseGit → Create Branch
Name Branch: название новой ветки
Base On: HEAD (master)
[x] Switch to new branch
«Коммит очередного кусочка работы»
Выполняется после выполнения некого изменения, суть которого целостная.
Меню → Git commit -> “имя ветки”
Отметить файлы, только нужные для данного конкретного коммита
Обязательно щелкнуть на «View Patch», и убедиться
в соответствии правилам ведения чистых коммита
В message ввести описание изменения, соответствующее правилам
«Отправка ветки на центральный репозиторий»
Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
Меню → TortoiseGit → Push
Выбираем в Local сперва master, потом нашу текущую ветку.
Remote заполняется при этом автоматически.
Название remote ветки должно быть идентично local
Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
«Ребейз относительно мастера»
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены.
Меню → 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
«Кратковременное сохранение состояния изменений»
Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
Меню → TortoiseGit → Stash Save
После этого дерево чисто, можно переключиться на другую ветку/мастер и так далее, поработать, после чего восстановить состояние, если переключиться обратно на рабочую ветку, и сделать
Меню → TortoiseGit → Stash Pop
Тем самым восстановив состояние изменения.
«Длительное сохранение состояния изменений»
Выполняется в конце рабочих суток, чтобы даже частичные изменения были забакаплены; либо при необходимости срочно переключиться на решение другой задачи, которая может занять значительно больше 5-10 минут.
Меню → Git Commit -> “ветка”
Отмечаем все-все изменения (Select/Deselect All)
В текст сообщения пишем «Partial commit»
Позже, для возврата к тому же состоянию как было до, переключаемся на рабочую ветку, и делаем
Меню → TortoiseGit → Show Log
Выделяем коммит, который идет в дереве сразу перед «Partial commit»
Правой кнопкой → Reset <ветка> to this
Reset type: Mixed
«Ревью ветки»
Выполняется на чистом дереве, временно сохраните изменения согласно пункта 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

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

Устанавливаются системные пакеты ssh-client и git
Создаётся приватный ключ:
ssh-keygen -t dsa -C «Ivan Petrov <work@mail>»
Настраивается ФИО и Емейл автора:
git config —global user.name «Ivan Petrov»
git config —global user.email work@mail»
Админу отсылается файл ~/.ssh/id_dsa.pub для прописывания доступов до репозиториев и серверов.

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

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

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

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

Обновление текущей ветки из центрального репозитория:
git pull
Отправка текущей ветки в центральный репозиторий:
git push origin branchname
Переключение на некоторую ветку:
git checkout branchname
При переключении на ветку, которой еще нет в локальном репозитории, будет создана локальная ветка, связанная с удалённой.
Создание новой ветки, базирующейся на текущей
git checkout -b branchname
Удаление веток
git branch -d branchname == удаление локальной уже слитой ветки
git branch -D branchname == принудительное удаление локальной ветки
git push origin :branchname == удаление ветки с центрального репозитория
Слияние ветки с текущей
git merge —no-ff branchname
Посмотреть какие файлы изменены в текущей директории:
git status
Просмотреть текущие изменения:
git diff
Сохранение текущих изменений:
git add именафайлов == добавить измененные/созданные файлы/директории
git rm именафайлов == добавить удаление файла/директории
git commit == сохранить добавленные изменения. Откроется редактор, чтобы ввести комментарий к коммиту
git commit -a == сохранить все добавленные изменения и все измененные файлы. Позволяет сохранять все изменения, если файлы не добавлялись.

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

«Начало работы над задачей».
Выполняется перед началом работы над задачей. Дерево должно быть без изменений.
git checkout master
git pull
git checkout -b branchname
«Коммит очередного кусочка работы».
Выполняется после выполнения некого изменения, суть которого целостная.
# проверяем, какие файлы изменились к текущему моменту
# удаляем если что-то попало совсем лишее
git status
# смотрим текст изменений, на предмет соответствия
# правилам ведения чистых коммитов. удаляем, если какой-либо мусор попал
git diff
# если какие-либо файлы не должны попасть в коммит (например,
# относятся к другому атомарному изменению.)
# то помечаем только те файлы, изменения которых нужно сохранить
git add …
git rm …
# сохраняем. -m можно опустить, тогда комментарий через редактор
git commit -m «Some commit message»
# если все на текущий момент созданные изменения нужно сохранить, то
# через git add добавляем новые файлы, а всё остальное сохраняем через
git commit -a -m «Some commit message»
«Отправка ветки на центральный репозиторий»
Выполняется после завершения работы, либо в конце каждого дня (чтобы был бакап на сервере), либо если нужно какие-то изменения показать коллеге.
git push origin branchname
Не следует делать push после каждого коммита, так как это потребует доступа до удалённого сервера, и, соответственно, времени, потраченного впустую.
«Ребейз относительно мастера».
Выполняется перед заливкой на сервер законченной задачи, когда все изменения уже закоммичены:
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
«Кратковременное сохранение состояния изменений».
Выполняется, если требуется временно приостановить работу над текущей веткой на короткое время (например, на ревью, или чтобы сделать какую-либо двухминутную задачу).
git reset HEAD .

Важно! После такой процедуры сохранения/восстановления, при следующем
git push origin branchname
Будет выдано предупреждение о непоследовательном изменении. Чтобы принудительно отправить изменения, следует добавить опцию -f.
git push -f origin branchname
Важно: не следует добавлять -f всегда, так как это спасёт от случайных опечаток в названии ветки, например.
«Ревью ветки».
Выполняется на чистом дереве, временно сохраните изменения согласно пункта 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: программное обеспечение для управления версиями, которое позволяет сотрудничать с членами проектной группы прямо там, где оно и должно быть: в командной строке.

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

Что такое Git?

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

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

Изучение git может быть пугающим, если у вас нет опыта программирования или совсем немного, но просто продолжайте думать о нем как о забавно выглядящих Документах Google, и у вас все будет хорошо! Забавный факт: git был изобретен Линусом Торвальдсом — тем же Линусом, который создал операционную систему с открытым исходным кодом Linux, которая теперь работает в огромных количествах Интернета, включая Google и Facebook.

Итак: git — это программа, которую вы устанавливаете на свой компьютер, которая затем обрабатывает за вас контроль версий. Что же такое контроль версий?

Что такое контроль версий?

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

Что ж, спасибо git, это так.Контроль версий происходит, когда вы устанавливаете git на свой компьютер. Git создан для создания этого нового каталога проекта и отслеживания всех изменений, которые вы вносите во все файлы, которые вы помещаете в этот каталог. По мере того, как дела идут и вы вносите дополнения и изменения, git делает «снимок» текущей версии. И это, друзья, контроль версий: внесите небольшое изменение, сделайте снимок, сделайте еще одно небольшое изменение, сделайте снимок… И сохраните все эти снимки в хронологическом порядке. Затем вы можете использовать git для перемещения вперед и назад по мере необходимости по каждой версии каталога вашего проекта.

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

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

Сотрудничество с Git

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

Git — это распределенная система контроля версий. Это означает, что в git есть команды, которые позволяют вам «проталкивать» ваши изменения на машины других людей и «переносить» их изменения на ваши. Между тем, GitHub хранит основную версию — фактически, главную библиотеку всех версий, когда-либо существовавших — проекта, чтобы вещи не становились слишком дикими и сумасшедшими.

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

Получение git

Шаг 1. Скачайте git

Выберите наиболее подходящий для вашей операционной системы: Mac OS, Linux или Windows.Он установится самостоятельно. Не волнуйтесь, если ничего не происходит,

Шаг 2. Откройте терминал

Извините, но вам просто нужно использовать командную строку. Итак, заткнитесь и оболочка: пользователи Linux, вы уже знаете, что делать. Для пользователей Mac это Finder -> Applications -> Utilities -> Terminal. Пользователи Windows (зачем вы вообще здесь?), Вам придется загрузить и установить эмулятор терминала.

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

Шаг 3. Сообщите git, что вы существуете

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

git config —global user.name ‘My_Name’ git config —global user.email ‘[email protected]’ git config —global color.ui ‘авто’

git config —global user.name ‘My_Name’

git config —global user.электронная почта ‘[email protected]’

git config —global color.ui ‘auto’

Эта последняя строка является необязательной; он сообщает git, что любой вывод команд git в терминале должен быть красиво закодирован по цвету, что намного проще для чтения и понимания. Причина, по которой мы помещаем «–global» перед каждым, состоит в том, чтобы не вводить эти команды конфигурации в следующий раз, когда мы запустим проект git в нашей системе. Таким образом, git знает, кто вы — навсегда.

Шаг 4.Создать новый каталог

А теперь пора попрактиковаться в создании образца проекта. Создайте пустой каталог для хранения всех ваших великолепных файлов проекта, которые скоро появятся (подсказка: $ mkdir (yourDirectoryNameHere). Затем вставьте компакт-диск и введите волшебные слова «git init»:

«Git init» создает новый репозиторий git, обычно называемый «репо». Представьте его как папку вашего проекта, только теперь с суперспособностями git. Репозиторий содержит все файлы вашего проекта, а также дополнительные, в основном невидимые материалы, которые git генерирует для отслеживания и хранения истории изменений каждого файла.

Начало рабочего процесса Git

На этом этапе вы создали репозиторий на своем собственном компьютере. Дополнительный материал, который помещает туда git, состоит из трех отдельных «деревьев» — не волнуйтесь, они полностью управляются и поддерживаются git. Основная область, с которой вы работаете, — это рабочий каталог, в котором хранятся ваши фактические файлы проекта. Также есть указатель, своего рода временная область хранения ваших последних изменений и дополнений. И Head, который указывает на последний коммит — самую последнюю сохраненную версию.

Совет

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

Шаг 5. Добавьте файл «README» и файлы проекта

Отличная идея — начать с создания файла «README», чтобы объяснить, что такое ваш проект, что в нем можно найти и т. Д. (README не обязательно должен быть энциклопедическим — нужны только основные факты, мэм.В настоящее время это тоже не написано — мы просто настраиваем каталог прямо сейчас). Это, кстати, простая работа с командной строкой, а не специфическая для git: «touch README.md»:

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

Шаг 6. Скопируйте репозиторий

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

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

Прелесть git в том, что он отслеживает все это за вас — кто что и где изменил — и все это организует.

Так что скопируйте — или клонируйте, на git-speak — ваше репо, выполнив команду «$ git clone / path / to / your_repository:»

(Если вы начинаете с копирования файла, который уже запущен кем-то другим, беря его с любого удаленного / сервера, ваша команда будет «$ git clone username @ host: / path / to / repository»).

Обратите внимание, как внутри нашего исходного каталога git-for-dummies теперь есть новый каталог копий git-for-dummies (рядом с нашим README). Причина, по которой он сообщает нам, что мы скопировали пустой репозиторий, заключается в том, что мы еще не сохранили наши новые дополнения (поставили наши коммиты).

Шаг 7. Проверить статус

(Кстати, за кулисами я добавил файл-заполнитель под названием «my_file.md», поэтому в нашем репо есть что-то помимо readme). Теперь, когда у нас есть несколько файлов в нашем репозитории, давайте посмотрим, как git обрабатывает их. Чтобы проверить текущий статус вашего репозитория, введите «git status»:

Шаг 8. Скажите git, чтобы он добавил ваши изменения

Статус Git сообщает нам, что у нас есть новые файлы, которые не были официально добавлены в процесс отслеживания git.Чтобы сказать git, что да, пожалуйста, будьте любезны с этими файлами, мы добавляем их в git. Как ни странно, это называется «постановкой», когда команда на самом деле «git add (имя файла здесь)»:

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

Шаг 9 git commit!

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

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

Тем не менее, ваше самое первое сообщение о фиксации при создании нового репозитория всегда будет «Начальная фиксация». Сообщение фиксации имеет формат «$ git commit -m» мое сообщение фиксации »:

Git идентифицирует каждую уникальную фиксацию, добавляя длинное шестнадцатеричное число к каждой фиксации. На скриншоте обратите внимание, что «a4105ea» — наша первая фиксация. Это похоже на подпись на вашем снимке.Если нам нужно вернуться в прошлое и получить доступ к этой конкретной версии нашего проекта, это «имя», которое вы могли бы использовать для определения нужной вам версии.

Шаг 10. Нет Шага 10, потому что ВЫ ЭТО СДЕЛАЛИ !!!! ???

Обратите внимание, как на скриншоте выше после фиксации мы выполнили «git status». git вернул прекрасное сообщение «Нечего фиксировать, рабочее дерево очищено» (помните наши деревья? Если нет, вернитесь и перечитайте раздел о рабочем процессе git выше). Это означает, что вы все в курсе.Этот git сделал снимок вашего проекта и сохранил его. Хотя в начале это похоже на детскую картинку.

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

Гм. Хорошо, да, значит, Git вас поддержит… по крайней мере, прямо сейчас на вашем компьютере.

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

Изображение функции через Pixabay.

Git — документация gittutorial

Предположим, что Алиса начала новый проект с репозиторием Git в / home / alice / project, и тот Боб, у которого есть домашний каталог на машина такая же, хочет внести свой вклад.

 bob $ git clone / home / alice / проект myrepo

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

Боб затем вносит некоторые изменения и фиксирует их:

 (редактировать файлы)
bob $ git commit -a
(при необходимости повторить)

Когда он готов, он говорит Алисе вытащить изменения из репозитория. в / дома / боб / myrepo. Она делает это с помощью:

 Алиса $ cd / home / alice / project
Алиса $ git pull / главная / боб / myrepo мастер

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

Таким образом, команда «pull» выполняет две операции: она извлекает изменения. из удаленной ветки, а затем объединяет их в текущую ветку.

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

Алиса может посмотреть, что сделал Боб без предварительного слияния, используя «выборку» команда; это позволяет Алисе проверять, что сделал Боб, используя специальный символ «FETCH_HEAD», чтобы определить, есть ли у него что-нибудь стоящее тянет, вот так:

 Алиса $ git fetch / home / bob / myrepo master
Алиса $ git log -p HEAD..FETCH_HEAD

Эта операция безопасна, даже если у Алисы есть незафиксированные локальные изменения. Обозначение диапазона «HEAD..FETCH_HEAD» означает «показать все, что доступно. из FETCH_HEAD, но исключить все, что доступно из HEAD ».Алиса уже знает все, что ведет к ее текущему состоянию (ГОЛОВА), и проверяет, что у Боба в его состоянии (FETCH_HEAD), чего нет у нее видел с этой командой.

Если Алиса хочет визуализировать, что делал Боб после разветвления их историй она может ввести следующую команду:

Здесь используется то же обозначение диапазона из двух точек, которое мы видели ранее с git log .

Алиса может захотеть посмотреть, что они оба сделали после разветвления. Она может использовать форму с тремя точками вместо формы с двумя точками:

Это означает «показать все, что доступно с любого из них, но исключить все, что доступно для них обоих «.

Обратите внимание, что эти обозначения диапазона могут использоваться как с gitk и «git log».

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

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

 alice $ git удаленное добавление bob / home / bob / myrepo

С его помощью Алиса может выполнить первую часть операции «вытягивания». в одиночку, используя команду git fetch , не объединяя их с собственными филиал, используя:

В отличие от полной формы, когда Алиса получает от Боба, используя сокращенная запись удаленного репозитория, настроенная с помощью git remote , что было извлеченный хранится в ветке удаленного отслеживания, в этом случае боб / мастер .Итак, после этого:

 Алиса $ git log -p мастер..bob / мастер

показывает список всех изменений, внесенных Бобом с тех пор, как он отошел от Главная ветвь Алисы.

После изучения этих изменений Алиса может объединить изменения в свою главную ветку:

 alice $ git merge bob / master

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

 alice $ git pull. пульты / боб / мастер

Обратите внимание, что git pull всегда сливается с текущей веткой, независимо от того, что еще указано в командной строке.

Позже Боб может обновить свое репо с последними изменениями Алисы, используя

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

 bob $ git config --get remote.origin.url
/ главная / алиса / проект

(Полная конфигурация, созданная git clone , видна с помощью git config -l и справочная страница git-config [1] объясняет значение каждого варианта.)

Git также хранит нетронутую копию основной ветки Алисы под имя «origin / master»:

 bob $ git branch -r
  origin / master

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

 bob $ git clone alice.org:/home/alice/project myrepo

В качестве альтернативы Git имеет собственный протокол или может использовать http; подробности см. в git-pull [1].

Руководство для начинающих по использованию Git.Полное руководство для начинающих, чтобы начать… | Чандреш | Код CS

Хотите знать, как использовать Git в своем проекте?

Это действительно просто.

Позвольте мне показать вам самый простой способ сделать это. Я бы посоветовал вам следовать этому руководству в вашей системе, и к концу этого руководства вы узнали бы обо всех командах git, которые вы будете использовать в своем новом проекте.

Если вы хотите посмотреть живые примеры, вы можете посмотреть его здесь:

Давайте начнем с теории.

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

Итак, Что такое git? Git — это распределенная система контроля версий для отслеживания изменений в исходном коде во время разработки программного обеспечения.

Вот как выглядит отслеживание изменений с использованием git и без него.

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

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

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

Теперь вы знаете, почему мы используем git? но Почему мы говорим, что это распределенная система контроля версий?

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

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

И… это все, что вам нужно знать.

Чтобы установить git в вашей системе, посетите https://git-scm.com/downloads, загрузите программное обеспечение и установите его в своей системе.

После завершения установки откройте свой терминал и введите

 git config -global user.name "Ваше имя" 
 git config -global user.email "Ваш адрес электронной почты"

Ваше имя и адрес электронной почты отображаются при каждой сделанной вами фиксации. , вот так:

Начнем с пустой папки.

Создайте новый файл, напишите в нем код и сохраните его, скажем, file1.html.

Первое, что вам нужно сделать, когда вы хотите начать использовать git в своем проекте, — это инициализировать git с помощью команды:

 git init

Примечание. Если у вас уже есть онлайн-репозиторий, скопируйте URL-адрес репозитория, а затем вы можно клонировать репозиторий с помощью этой команды.
git clone your_repository_url

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

 git add -A

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

 git status

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

Чтобы зафиксировать изменения, введите

 git commit -m "ваше сообщение"

Это создаст новую фиксацию.

Если вы проверите статус сейчас, то увидите, что после фиксации изменений не было.

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

 git log

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

Внесите некоторые изменения в свой файл и сделайте еще одну фиксацию, как описано выше.

Внесите еще несколько изменений и создайте новый файл, скажем, file2.html, и сохраните его.

Введите git status , и вы увидите, что неотслеживаемые файлы и неустановленные изменения отмечены красным цветом.

Теперь, если вы просто хотите добавить изменения file1 в новую фиксацию, вы можете ввести.

 git add file1_path

И если вы проверите статус, он покажет вам только file1 зеленым цветом.

Теперь вы можете сделать коммит, если хотите, как и мы, но что, если вы передумаете и захотите добавить file2 в новый коммит.Введите «git add -A» , и он добавит файлы.

Зафиксируйте эти изменения, как мы это делали раньше.

Теперь Предположим, вы хотите проверить код своего проекта на предмет определенного коммита. Как бы Вы это сделали?

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

 git checkout hash

И вы можете увидеть код нашего проекта для этого конкретного коммита.

Проверьте журнал git еще раз, и он покажет вам только коммиты до фиксации проверки.

Но теперь предположим, что вы хотите проверить свою последнюю фиксацию. Введите

 git checkout your_branch_name

В этом случае имя нашей ветки — master (оно создается по умолчанию для вас, когда вы инициализируете git в проекте).

Проверьте «git log», и вы увидите всю свою фиксацию, и у вас будет последний код фиксации в главной ветке.

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

 git checkout -b new_branch_name

Здесь мы переключаемся на новую ветку со всеми фиксациями до тех пор, пока не проверены фиксации в текущей ветви. Здесь флаг «-b» используется для создания новой ветки и команды git checkout для переключения на новую ветку.

Давайте еще раз внесем некоторые изменения.

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

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

 git checkout branch_name

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

Чтобы объединить изменения, сделанные в ветке feature1, с вашей основной веткой. Введите

 git merge branch_name_from_which_you_want_to_merge_changes

И это объединит все ваши изменения из ветки feature1 в вашу текущую ветку, которая в данном случае является главной ветвью.

Проверьте «git log» , и теперь у нас есть изменения feature1 в главной ветке.

Итак, вы закончили со всеми изменениями и хотите поделиться своим кодом с кем-нибудь или, возможно, просто хотите сохранить свои изменения в сервисе, скажем, GitHub.

Для этого перейдите на GitHub.com и создайте новую учетную запись, если у вас ее еще нет.

Создайте новый репозиторий.

Выберите, хотите ли вы сделать ваш репозиторий общедоступным или частным. Я выберу личное.

Щелкните Создать репозиторий

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

Введите:

 git push origin branch_name

, и это перенесет весь ваш код из основной ветки в GitHub.

Если вы хотите предоставить доступ к хранилищу члену группы или соавтору.

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

Щелкните « Manage Access »

Щелкните «Пригласить соавтора» . Введите их имя пользователя GitHub или адрес электронной почты, если они получат от вас приглашение.

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

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

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

Итак, как вы перенесете изменение с GitHub на ваш локальный.

 git pull origin branch_name

И это перенесет последние изменения из GitHub в главную ветку в ваш локальный.

И это все, что вам нужно знать, чтобы начать использовать git в любом проекте.

Надеюсь, вы найдете это полезным!

Git для начинающих — SitePoint

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

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

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

Установка Git

На официальном сайте Git есть подробная информация об установке в Linux, Mac или Windows.В этом случае мы будем использовать Ubuntu 13.04 для демонстрационных целей, где вы устанавливаете Git, используя apt-get .

  sudo apt-get install git

Начальная конфигурация

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

  мкдир my_git_project
компакт-диск my_git_project

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

  git init

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

  git config --global user.name 'Shaumik'
git config --global user.email '[email protected]'
git config --global color.ui 'авто'

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

Кроме того, мы установили цвет пользовательского интерфейса на auto , чтобы выходные данные команд Git в терминале имели цветовую кодировку. Причина, по которой мы добавляем к команде префикс --global , заключается в том, чтобы не вводить эти команды конфигурации при следующем запуске проекта Git в нашей системе.

Промежуточные файлы для фиксации

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

Проверьте состояние вашего репозитория

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

  git статус

Добавление файлов для Git для отслеживания

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

  git добавить my_file

Повторная проверка статуса репозитория показывает, что был добавлен один файл.

Чтобы добавить несколько файлов, мы используем следующее (обратите внимание, что мы добавили еще один файл в демонстрационных целях).

  git добавить myfile2 myfile3

Вы можете использовать git add рекурсивно, но будьте осторожны с этой командой.Есть определенные файлы (например, скомпилированные файлы), которые обычно хранятся вне репозитория Git. Если вы используете , добавьте рекурсивно, он добавит все такие файлы, если они есть в вашем репозитории.

Удаление файлов

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

  git rm --cached [имя_файла]

Подтверждение изменений

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

  git commit -m «Моя первая фиксация»

Предоставьте полезное сообщение о фиксации, потому что оно поможет вам определить, что вы изменили в этой фиксации. Избегайте слишком общих сообщений типа «Исправленные ошибки». Если у вас есть средство отслеживания проблем, вы можете отправлять сообщения вроде «Исправлена ошибка № 234».Хорошей практикой является добавление префикса имени ветки или функции к сообщению о фиксации. Например, «Управление активами — добавленная функция для создания PDF-файлов активов» — это содержательное сообщение.

Git идентифицирует коммиты, добавляя длинное шестнадцатеричное число к каждой фиксации. Обычно вам не нужно копировать всю строку, и первых 5-6 символов достаточно, чтобы идентифицировать ваш коммит. На скриншоте обратите внимание, что 8dd76fc идентифицирует нашу первую фиксацию.

Дальнейшие коммиты

Давайте теперь изменим несколько файлов после нашей первой фиксации.После их изменения мы замечаем через git status , что Git замечает изменение в файлах, которые он отслеживает.

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

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

  git add -u

Вы можете избежать этой команды, добавив префикс -a к git commit , который добавляет все изменения в отслеживаемые файлы для фиксации.Однако этот процесс очень опасен, поскольку может нанести вред. Например, предположим, что вы открыли файл и по ошибке изменили его. Если вы выберете их выборочно, вы заметите изменения в каждом файле. Но если вы добавите в коммит -a , все файлы будут зафиксированы, и вы не заметите возможных ошибок.

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

  git commit

Управление вашим проектом

Чтобы проверить историю вашего проекта, вы можете запустить следующую команду.

  журнал git

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

  git show

Где <хэш> — шестнадцатеричное число, связанное с фиксацией. Поскольку это руководство предназначено для новичков, мы не будем рассказывать, как вовремя вернуться к состоянию конкретного коммита или как управлять ветвями.

Размещение кода в облаке

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

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

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

  git удаленное добавление источника https://github.com/sdaityari/my_git_project.git
git push -u origin master

Заключение

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

10 лучших руководств по Git для начинающих

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

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

1. Профессиональный Git

Pro Git — это бесплатная онлайн-книга Скотта Чакона, разработчика, работающего над GitHub. Прекрасная структура книги и набор тем позволяют вам сразу переходить к главам, имеющим отношение к вашему уровню знаний Git.Независимо от того, являетесь ли вы полным новичком или опытным профессионалом, в этой книге есть что-то для вас.

2. Погружение в Git

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

3. Книга сообщества Git

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

4. Git снизу вверх

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

5. Git Magic

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

~~6. Git по примеру~~

Примечание редактора: Этот учебник больше не существует, и ссылка была удалена.

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

7. Простое управление версиями с помощью Git

Этот отличный учебник по Git на Nettuts + дает вам достаточно информации, чтобы начать работу.В этом руководстве замечательно то, что в нем также есть раздел об использовании GitHub.

8. Git в действии

Этот скринкаст покажет вам на примере, как работает Git; он длится немногим менее 18 минут, поэтому его определенно стоит посмотреть, поскольку веб-дизайн так важен.

9. Введение в Git для веб-дизайнеров

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

10. Визуальный справочник Git

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

Другие замечательные ресурсы по Git

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

Git Tutorial: Как редактировать проекты с помощью Git: это руководство по Git для начинающих, которое включает инструкции по установке.
Введение в Git: посмотрите этот скринкаст на GitHub, который знакомит с основными концепциями Git.
Как установить Git: это ответ на Stack Exchange, в котором рассказывается, как установить Git в Windows, Mac OS X и Linux.
Git The Basics Tutorial: записанное из двух частей видео, в котором Барт Трояновски рассказывает об основах Git (доступен в формате PDF).
Everyday GIT с 20 командами или около того: здесь вы можете изучить основы Git с помощью наиболее распространенных команд (с примерами использования команд в реальных сценариях).
Начиная с Git: шпаргалка: краткое введение в Git, в котором обсуждаются основные действия, такие как фиксация в репозитории и добавление файлов для отслеживания версий.
Начало работы с Git: это 6-страничное руководство по Git в виде шпаргалки от компании Dzone, занимающейся технологическим изданием, доступно в виде PDF-файла, который вы можете распечатать.
gittutorial Страница руководства: это руководство по Git является официальной страницей руководства в пакете Git.
Git для ленивых: это руководство поможет вам как можно быстрее начать работу с Git.
git ready: на этом ресурсе собраны быстрые советы по Git, сгруппированные по уровню сложности (начальный, средний и продвинутый).
Git_Guide: это руководство по Git в стиле часто задаваемых вопросов охватывает самые популярные темы для начинающих.
Вводное руководство по системе управления версиями Git: это руководство, посвященное шести ревизиям, представляет собой краткий ресурс для ознакомления с Git.
Играем в Git как на скрипке: узнайте, как создавать псевдонимы команд Git (ярлыки) для ускорения рабочего процесса управления версиями с помощью этого онлайн-ресурса.
Иллюстрированное руководство по Git в Windows: замечательное руководство по установке и использованию Git в Windows (с использованием mysysgit, графического интерфейса для Git).
Начало работы с Git и GitHub в Windows: руководство для пользователей Windows, в котором рассказывается, как использовать Git с популярным сайтом социального программирования GitHub.
Ага! Моменты изучения Git: Калид Азад делится некоторыми мыслями и уроками о своем первом опыте работы с Git.
Контроль версий для дизайнеров: в этом руководстве Git обсуждаются принципы и концепции, лежащие в основе систем контроля версий.
Знакомство с Git: основы: пошаговое руководство по Git, чтобы вы начали с практического подхода.
Знакомство с GitHub: если вас интересует Git, скорее всего, это из-за GitHub. Из этого руководства вы узнаете, как приступить к работе с GitHub.
Концептуальное понимание Git. В этом руководстве по Git основное внимание уделяется основам работы Git.
Git: ваш новый лучший друг: это вводное руководство по SitePoint знакомит читателя с контролем версий и Git.
Линус Торвальдс на Git: посмотрите это видео в Google Talk, в котором Линус Торвальдс рассказывает о Git.

Сообщение обновлено [21 февраля 2014 г.]: Один из наших читателей написал мне по электронной почте, что книга «Pro Git» (№1 в этом списке) перемещена. Он предоставил обновленную ссылку. Мы обновили ссылку и скриншот.

Связанное содержимое

7 лучших руководств по Git для быстрого начала работы

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

В мире контроля версий Git лидирует!

Что такое Git?

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

Но что это на самом деле означает? Проще говоря, Git — это система, отслеживающая контент. Он отслеживает контент, предоставляя историю всех изменений, внесенных разработчиками в код в различных файлах проекта. Каждый раз, когда в проект вносятся изменения и он сохраняется, Git создает так называемый коммит . Фиксация представляет собой состояние всех файлов в проекте в определенный момент времени.

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

Как работает Git?

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

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

Преимущества Git

Все процессы атомарны. Это означает, что Git обрабатывает набор изменений как одну операцию.
Git позволяет разработчикам поддерживать большое количество отдельных веток кода. Создание, удаление и объединение этих веток происходит быстро и прозрачно.
Еще одна замечательная особенность Git заключается в том, что он использует модель данных для обеспечения целостности шифрования всего в репозитории.Это невозможно в других системах контроля версий.
Поскольку Git становится стандартом для управления версиями, он интегрирован в большинство IDE, таких как Intelli J, Visual Studio, Code и Atom, и это лишь некоторые из них!
Сильная поддержка сообщества: сообщество Git очень большое и очень полезное.
Git сохраняет ваш код в облаке, поэтому служит резервной копией вашей локальной копии.

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

7 лучших руководств по Git

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

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

1. Руководство для начинающих по Git и GitHub

На сайте freecodecamp.org, вы найдете Руководство для начинающих по Git и GitHub, которое отлично подходит для новичков, которые хотят изучить следующее:

Основные инструкции по установке
Настройка среды Git
Как начать проект в Git
Разница между Git и GitHub

2. Что такое Контроль версий

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

Из этого руководства по Git вы узнаете:

Установка Git на Mac, Windows и Linux
Настройка репозитория
Контроль версий с помощью Git
Сотрудничество в Git

3. Git: простое руководство

В этом очень простом руководстве вы узнаете, как:

Установить Git
Настройте среду как на Mac, так и на Windows (включая автозаполнение и цветные команды на Mac)
Создать новый репозиторий
Оформить заказ в репозиторий
Используйте рабочие процессы (основа ветвления, обновления, слияния и тегирования)

4.Введение в Git и GitHub для начинающих

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

Установка Git и создание учетной записи GitHub
Создание локального репозитория Git
Добавление файла в промежуточную среду
Создание нового репозитория на GitHub
Отправка ветки на GitHub
Получение изменений на GitHub обратно на ваш компьютер

5.Привет, мир, проект

Проект Hello World руководства GitHub учит вас использовать GitHub для создания базовой компьютерной программы. Это руководство познакомит вас с основами Git:

Создание и использование репозитория
Открытие нового филиала и управление им
Внесение изменений в файл и отправка их на GitHub при фиксации
Открытие и объединение запроса на вытягивание

6. Изучите Git достаточно, чтобы быть опасным

LearnEnoughGit to BeDangerous — отличный ресурс для изучения и освоения Git, и я рекомендую посетить этот сайт всем, кто хочет изучить Git.Сначала он представляет собой введение в управление версиями в Git. Во-вторых, автор делится уроками из своего раннего опыта работы с Git. И самое главное, обсуждаются принципы и концепции систем контроля версий.

В этом руководстве вы узнаете:

Установка и настройка Git
Создание репозитория
Добавление HTML-тегов и структуры

7. Git-SCM

Любой, у кого есть базовые навыки работы с командной строкой UNIX, но не знакомы с Git, найдет это руководство по Git полезным.Это оригинальный веб-сайт с открытым исходным кодом Git-SCM (управление исходным кодом), поддерживаемый сообществом Git.

Из этого туториала Вы узнаете, как:

Создать репозиторий Git
Просмотр версий проекта
Анализ истории с помощью коммитов
Управление ветвями

Дальнейшее обучение

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

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

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

Чего вы ждете? Запишитесь сейчас!

Учебный лагерь Git и GitHub

Посмотреть курс

Даниэль де Оливейра

Полная шпаргалка для начинающих

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

Приступим!

Понимание рабочего процесса GIT

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

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

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

Каждый может использовать GIT, поскольку он доступен для Linux, Windows, Mac и Solaris. У программного обеспечения может быть крутая кривая обучения, но есть много учебных пособий, готовых вам помочь.

Основные команды GIT

Вот несколько основных команд GIT, которые вам необходимо знать:

git init создаст новый локальный репозиторий GIT.Следующая команда Git создаст репозиторий в текущем каталоге:

 git init

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

 git init [название проекта]

git clone используется для копирования репозитория. Если репозиторий находится на удаленном сервере, используйте:

 git clone имя пользователя @ хост: / путь / к / репозиторию

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

 git clone / путь / к / репозиторию

git add используется для добавления файлов в промежуточную область.Например, основная следующая команда Git проиндексирует файл temp.txt:

 git add

git commit создаст моментальный снимок изменений и сохранит его в каталоге git.

 git commit –m «Сообщение для перехода к фиксации здесь»

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

 git config --global user.email [email protected]

Флаг –global сообщает GIT, что вы собираетесь использовать этот адрес электронной почты для всех локальных репозиториев. Если вы хотите использовать разные адреса электронной почты для разных репозиториев, используйте команду ниже:

 git config --local user.email [email protected]

git status отображает список измененных файлов вместе с файлами, которые еще предстоит подготовить или зафиксировать.

 git статус

git push используется для отправки локальных коммитов в главную ветку удаленного репозитория. Вот основная структура кода:

 git push origin <мастер>

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

 команда git checkout -b <имя-ветки>

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

 git checkout <имя-ветки>

git remote позволяет просматривать все удаленные репозитории. Следующая команда выведет список всех подключений вместе с их URL-адресами:

 git remote –v

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

 git удаленное добавление источника

Между тем следующая команда удалит соединение с указанным удаленным репозиторием:

 git remote rm <имя-репозитория>

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

 ветка git

Если вы хотите удалить ветку, используйте:

 git branch –d <имя-ветки>

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

 git pull

git merge используется для слияния ветки с активной.

 git merge <имя-ветки>

git diff выводит список конфликтов. Чтобы просмотреть конфликты с базовым файлом, используйте

 git diff --base <имя-файла>

Следующая основная команда используется для просмотра конфликтов между ветвями перед их объединением:

 git diff <ветка-источник> <ветка-цель>

Чтобы перечислить все существующие конфликты, используйте:

 git diff

git tag отмечает определенные коммиты.Разработчики обычно используют его для обозначения точек выпуска, таких как v1.0 и v2.0.

 git tag

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

 совершить 15f4b6c44b3c8344caasdac9e4be13246e21sadw
Автор: Алекс Хантер 
Дата: Пн, 1 октября, 12:56:29, 2016 -0600

Команда git reset сбросит индекс и рабочий каталог до последнего состояния git commit.

 git reset --hard HEAD

git rm можно использовать для удаления файлов из индекса и рабочего каталога.

 git rm filename.txt

Команда git stash временно сохранит изменения, которые не готовы к фиксации. Таким образом, вы сможете вернуться к этому проекту позже.

 git stash

git show — это команда, используемая для просмотра информации о любом объекте git.

 git показать

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

 git fetch origin

git ls-tree позволяет просматривать объект дерева вместе с именем, режимом каждого элемента и значением SHA-1 большого двоичного объекта. Допустим, вы хотите увидеть ГОЛОВУ, введите:

 git ls-tree HEAD

git cat-file используется для просмотра информации о типе и размере объекта репозитория.Используйте параметр -p вместе со значением SHA-1 объекта, чтобы просмотреть информацию об определенном объекте, например:

 git cat-file –p d670460b4b4aece5915caf5c68d12f560a9fe3e4

git grep позволяет пользователям выполнять поиск определенных фраз и слов в определенных деревьях, рабочем каталоге и промежуточной области. Для поиска www.hostinger.com во всех файлах введите:

 git grep "www.hostinger.com"

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

 гитк

git instaweb позволяет просматривать локальный репозиторий в интерфейсе git-web. Например:

 git instaweb –httpd = webrick

git gc очистит ненужные файлы и оптимизирует локальный репозиторий.

 git gc

git archive позволяет пользователям создавать zip- или tar-файл, содержащий компоненты единого дерева репозитория.Например:

 git архив --format = tar master

git prune удаляет объекты, не имеющие входящих указателей.

 git prune

git fsck выполняет проверку целостности файловой системы git и выявляет все поврежденные объекты.

 git fsck

git rebase используется для применения определенных изменений из одной ветки в другую. Например:

 git rebase master

Шпаргалка по основным командам GIT в формате.pdf

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

Скачать (размер: 1,2 МБ)

Заключение

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

Практикуйте эти команды и максимально используйте свои развивающиеся навыки! Удачи!

Domantas возглавляет отделы контента и SEO, предлагая свежие идеи и нестандартные подходы.