Рейтинг: 4.3/5.0 (1890 проголосовавших)Категория: Руководства
Библиотека сайта или "Мой Linux Documentation Project"
Семь полезных советов для тех, кто начинает использовать GitОригинал: 7 Useful Git Tips for Beginners
Автор: Tobias Gunther
Дата публикации: Sep 4 2013
Перевод: Н.Ромоданов
Дата перевода: январь 2015 г.
Действительно, когда я впервые начал использовать Git для управления версиями, я не был уверен, что окупятся все вложения, которые я затратил на его изучение. Ветвление (branching ), подготовка (staging ), накопление (stashing ) — все эти термины Git были для меня чужды.
Сегодня я не могу представить свою жизнь без Git. Git не только дал мне столь необходимую в моей работе возможность управлять версиями, он также сделал меня более лучшим программистом.
Ниже приведен ряд простых советов, которые помогут вам сделать Git важной частью вашего рабочего процесса веб-разработки.
Совет 1: Потратьте немного времени на изучение основ GitИзучение основ не означает, что вы должны от начала до конца прочитать всю документацию по Git (хотя, если вы считаете, что это надо сделать, я бы не отговаривал вас от этого).
Есть очень много различных руководств и учебников по Git, так что я уверен, что есть что-то, что соответствует вашим личным предпочтениям и оптимальному стилю обучения.
Есть несколько образовательные ресурсов по Git, с которыми желательно ознакомиться:
Совет 2: Начните с простой схемы использования GitЛучше меньше, да лучше.
Часто Git ассоциируется со сложными рабочими процессами. Но позвольте мне сказать следующее: для того, чтобы сразу воспользоваться преимуществами Git, вам не нужно быть абсолютным мастером его использовании.
Рабочие процессы, в которых используется Git, могут быть крайне просты - и в большинстве случаев "простой процесс" это все, что вам нужно. Конечно, вы можете пользоваться несколькими удаленными репозиториями, делать запросы на их изменения, перебазировать свои изменения и т.д. но вы это делать не должны, если это вам не нужно.
Если начать с простого рабочего процесса, то позже, когда вам потребуются дополнительные расширенные возможности Git, вы можете увеличить его сложность. К дополнительным возможностям вы можете обратиться только тогда, когда вам это будет нужно.
Ниже приведено несколько примеры различных рабочих процессов с использованием Git, откуда вы можете почерпнуть идеи и вдохновение:
Совет 3: Перестаньте бояться делать ошибки
В Git важно то, что он защищен почти на 100%.
Если вы получите следующее, то сможете спокойно спать по ночам:
Концепция ветвления в Git является одной из самых полезных особенностей, о которой вы можете узнать в самом начале. Ветвление позволяет вести различные варианты разработки одного и того же проекта и ключевым компонентом будет эффективное использование Git.
Сначала может казаться, что эта возможность не настолько важна, но как только вы полностью разберетесь с концепцией ветвления, вы будете удивляться, как вы могли бы жить без этой возможности.
Хотя в других системах управления версиями также использует понятие ветвления, Git является первой системой, которая действительно делает его простым в использовании и полезным.
Ниже перечислены некоторые ресурсы, с которыми следует ознакомиться для того, чтобы понять в Git концепцию ветвления:
Совет 5: Изучите использование области подготовки Staging AreaЕсли вы всего лишь собираете из изменений коммит. то наиболее полезной возможностью является контроль версий. Он гарантирует, что коммит может быть легко отменен без всяких побочных эффектов. Привычка делать частые коммиты поможет вашим коллегам также легче понимать, в чем состоят ваши изменения.
Поскольку вы можете точно определить, какие именно изменения должны быть внесены в следующий коммит, в Git можно проще делать более гранулированные коммиты, чем в любой другой системе контроля версий (VCS).
Это возможно благодаря функции Git, которая называется областью изменений (staging area ).
Научитесь пользоваться этой возможностью, поскольку это одна из самых важных и уникальных возможностей Git.
Некоторые ресурсы, описывающих эту возможность Git:
Хотя использование графического интерфейса, безусловно, не является обязательным требованием, я очень рекомендую им пользоваться.
Использование графического интерфейса позволяет проще решать многие задачи и будет начальном этапе для вас очень полезным.
В конце концов, польза от Git состоит не в том, чтобы наизусть выучить команды и параметры, а в том, чтобы упроститьло ваш рабочий процесс кодирования. Если с помощью графического интерфейса можно упростить процесс кодирования, то нет никаких причин, чтобы это делать более сложным образом.
Ниже описаны некоторые графические интерфейсы для Git, с которыми рекомендуется ознакомиться:
Использование графического интерфейса не освобождает вас от изучения основ, но как только вы достигните должного уровня мастерства в Git, изучите и те инструменты, которые сделают вашу жизнь проще.
Совет 7: Настройте себя на использование GitИспользование нового инструмента может в течение первых нескольких дней быть причиной некоторой головной боли. Единственный способ пройти через нее — это продолжать обучение.
Не оглядывайтесь назад; станьте полным приверженцем этой технологии. Внедрение Git в ваш обычный процесс кодирования скоро окажется одним из самых больших и важных событий, которые с вами случились.
Избегайте делать исключения, например, «я буду использовать Git в этих проектах, но не в других». По крайней мере, вначале.
Разработка в стиле Git даст вам на практике много преимуществ, сделает многое существенно проще, поскольку вам будет известно, что в текущем проекте, над которым вы работаете в настоящее время, используется система контроля версий, и, самое главное делает использование Git частью ваших привычек кодирования.
В будущем, вы увидите, что лишь в редких случаях вам не потребуется Git. До тех пор, пока вы явно не столкнетесь с подобной ситуацией, вы во всех случаях можете пользоваться Git.
Еще на самом первом этапе вашего пути к мастерству с Git поверьте в него на все 100%.
Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь .
Только зарегистрированные пользователи могут оценивать и комментировать статьи.
Противостояние изменениям - основная черта человека. Если в то время, когда вы начинали работу с системами контроля версий, не было Git - весьма вероятно, что вы начинали с Subversion. Часто люди говорят, что Git слишком сложен для начинающих. Тем не менее, я позволю себе с вами не согласиться.
В этой статье я расскажу, как можно использовать Git в работе с вашими проектами. Будем считать, что вы создаете проект с нуля, и хотите использовать Git в качестве системы контроля версий. После ознакомления с основными командами, мы ознакомимся с тем, как можно выложить ваш код на GitHub.
В этой статье речь пойдет об основных вещах - как инициализировать проект, как управлять новыми и уже существующими файлами, и как хранить свой код в облаке. Мы опустим некоторые сложные вещи, как ветвление, так как статья ориентирована на начинающих.
Установка GitНа официальном сайте Git есть подробная информация о его установке на различные системы - Linux, Mac, Windows. В нашем случае мы будем использовать Ubuntu 13.04, и Git мы будем устанавливать посредством apt-get .
Начальная конфигуацияСоздадим директорию, в которой мы будем работать. Также вы можете использовать Git для работы с уже существующим проектом, и в таком случае вы не будете создавать демонстрационную директорию, как это описано ниже.
Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init. которая создает директорию .git со всей информацией о вашем проекте.
Далее необходимо указать наше имя и почтовый адрес. Вы можете сделать это следующим образом, заменив значения вашими данными.
Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.
Также мы устанавливаем цвет интерфейса в значение auto. так что вывод команд Git будет цветным. Мы добавляем префикс --global к этим командам для того, чтобы эти значения использовались во всей системе, и не было необходимости их задавать для каждого отдельного проекта.
Готовим файлы для коммитаСледующим шагом мы создадим несколько файлов. Можно использовать для этого любой текстовый редактор. Заметьте, что если вы инициализируете Git в уже существующем проекте, вам не нужно делать этот шаг.
Теперь, когда в вашем проекте есть файлы, давайте посмотрим, как Git с ними обращается. Чтобы проверить текущий статус репозитария, используйте команду git status
На этом этапе Git не следит ни за одним из наших файлов. Необходимо специально добавить файлы в Git, чтобы это происходило. Для этого воспользуемся командой add.
Проверив статус репозитария видим, что один из файлов уже добавлен в него.
Чтобы добавить несколько файлов, используем следующее (заметьте, что первый файл мы добавили ранее, так что добавляем только оставшиеся два).
Можно использовать git add рекурсивно, но будьте осторожны с этой командой. Есть некоторые файлы (например, скомпилированные программы), которые не должны быть добавлены в систему контроля версий. Если вы используете git add рекурсивно, такие файлы также попадут в репозитарий.
Удаляем файлыПредставим, что вы случайно добавили в репозитарий файл, который не должен был туда попасть. Или же вы хотите убрать из системы контроля версий какой-либо файл. В общем, команда git rm не просто удалит файл из репозитария, но и физически удалит его с диска. Чтобы Git перестал отслеживать файл, но он остался на диске, используйте следующую команду:
Коммитим измененияКак только вы добавили все необходимые файлы, вы можете закоммитить (зафиксировать) их в Git. Представьте, что коммит - это снимок состояния проекта на определенном этапе, к которому вы можете вернуться в любой момент времени, и увидеть состояние проекта на тот момент. С каждым коммитом ассоциируется сообщение, которое задается аргументом после префикса -m
Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика - указывать в сообщении имя ветки или улучшения. Например, “Управление активами - добавлена возможность генерировать PDF на основе актива” - понятное и доходчивое сообщение.
Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом 8dd76fc .
Дальнейшие коммитыДавайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.
Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff. Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff <файл> .
Необходимо проиндексировать изменения, и закоммитить их. Все измененные файлы проекта можно добавить на коммит следующей командой:
Можно избежать использования этой команды, если добавить параметр -a к git commit. Эта команда проиндексирует все измененные файлы, и закоммитит их. Но такой подход может быть довольно опасным, так по ошибке можно закоммитить то, что не хотелось. Например, скажем, что вы открыли файл, и случайно его изменили. При индексировании измененных файлов вы будете оповещены об изменениях в каждом файле. Но если вы отправите на коммит все измененные файлы не глядя с помощь. git commit -a. то будут закоммичены все файлы, включая те, которые вы коммитить не хотели.
Как только вы проиндексировали файлы, можно приступать к коммиту. Как упоминалось ранее, к коммиту можно указать сообщение с помощью ключа -m. Но также можно указывать и многострочные комментарии с помощью команды git commit. которая открывает консольный редактор для ввода комментария.
Чтобы просмотреть историю проекта, можно воспользоваться следующей командой:
Она отобразит полную историю проекта в виде списка коммитов и информацию о них. Информация о коммите содержит хеш коммита, автора, время и сообщение коммита. Есть множество видов команды git log. с которыми придется познакомиться в случае использования ветвления в Git. Чтобы посмотреть детали конкретного коммита, и измененные файлы, выполните следующую команду:
где <хеш_коммита> - шестнадцатеричный номер, ассоциированный с коммитом. Так как данное руководство предназначено новичкам, мы не будем рассматривать, как вернуть состояние на момент конкретного коммита, или как управлять ветками.
Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://www.sitepoint.com/git-for-beginners/
Перевел: Станислав Протасевич
Урок создан: 23 Мая 2014
Просмотров: 33495
Правила перепечатки
Ищите способ создавать мобильные приложения с помощью обычных средств и языков? К примеру HTML5? Тогда советуем посмотреть данную подборку.
Набор элементов пользовательского интерфейса с ориентацией на ретина дисплеи.
Классные иконки на тему “лето”.
Набор иконок на тему “дома и постройки” в оригинальном стиле.
Десятка бесплатных и полезных приложений, которые пригодятся дизайнерам.
Хотите быстро изучить JavaScript и jQuery?
Предлагаю использовать самый эффективный и современный метод обучения - видеокурс .
За счет получения информации сразу по двум каналам (зрение и слух) эффективность обучения значительно превосходит обучение по книгам. А домашние задания и онлайн-тесты позволят вам постоянно думать на изучаемом языке и сразу проверять свои знания!
Более 100 видеоуроков на одном DVD.
Видеокурс "HTML с нуля"
Если вы давно хотите как следует изучить HTML, то у меня для Вас есть отличная новость!
Вы можете совершенно бесплатно получить полноценный курс по HTML из моего платного сборника. 33 видеоурока от Евгения Попова!
Видеокурс "CSS с нуля"
Если вы уже изучили HTML и хотите двигаться дальше, то следующим шагом будет изучение технологии CSS.
Так же, как и в случае с HTML, вы можете совершенно бесплатно получить полноценный курс по СSS из моего платного сборника. Вас ждет 45 подробных видеоуроков от Евгения Попова!
Видеокурс "Домен и хостинг"
Если вы хотите разобраться с понятиями домена и хостинга, научиться создавать базы данных, закачивать файлы сайта на сервер по FTP, создавать поддомены, настраивать почтовые ящики для своего сайта и следить за его посещаемостью, то этот курс создан специально для вас!
Получать новые уроки на E-mail:В состав Git входит утилита git config. которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git и его внешний вид. Эти параметры могут быть сохранены в трёх местах:
В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME (C:\Documents and Settings\$USER или C:\Users\$USER для большинства пользователей). Кроме того Git ищет файл /etc/gitconfig. но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.
Установка имени и электронной почтыУстановка имени и адреса электронной почты. Каждый коммит в Git'е содержит эту информацию, и она включена в передаваемые коммиты и не может быть далее изменена:
Параметры установки окончаний строкТакже, для пользователей Unix/Mac:
Выбор редактораПо умолчанию Git использует стандартный редактор, установленный в системе. Для выбора другого редактора необходимо выполнить команду:
Утилита сравненияПо умолчанию Git использует стандартную утилиту сравнения, для её смены необходимо выполнить команду:
Просмотр настроекПросмотр всех настроек выполняется командой git config --list :
Также вы можете проверить значение конкретного ключа, выполнив git config <ключ> :
Псевдонимы в GitМожно настроить псевдонимы (alias) для любой команды с помощью git config .
Это означает, что, например, вместо набирания git commit. вам достаточно набрать только git ci .
Основные командыПредлагаем короткую и компактную шпаргалку-руководство по Git для новичков. Если вы никогда не слышали что такое Git - не читайте эту шпаргалку.
Для того чтобы создать новый репозиторий git необходимо открыть папку где вы хотите его разместить и выполнить команду Создать локальную рабочую копию репозитория можно командой когда используется удаленный сервер, команда будет Ваш локальный git репозиторий состоит из трех "сущностей". Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area), содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали. Чтобы подготовить изменения (добавить их в Индекс) используйте Это первый шаг в основном рабочем процессе. Сделать коммит подготовленных изменений можно командой Теперь изменения закреплены в локальном репозитории и на них указывает HEAD, но еще не в удаленном репозитории.
Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните Можно изменить master на любую другую ветвь чтобы отправить изменения на неё.
Если вы еще не клонировали существующий репозиторий и хотите подключить ваш к удаленному, вам нужно добавить его, выполнив Теперь вы можете отправлять изменения на удаленный репозиторий.
Ветки используются для разработки функционала изолированного от остального. Ветка master используется по умолчанию когда вы создаете репозиторий. Используйте другие ветки для разработки и слияние в master когда разработка завершена.
Создать новую ветку с названием "feature_x" и переключиться на неё можно командой переключиться обратно на master удалить ветку ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием пока вы не отправите её туда Обновить ваш локальный репозиторий, можно командой которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой. Для того чтобы слить другую ветку с активной (например master), используйте команду В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов, путем ручного редактирования файлов указанных git. После изменений вам надо пометить их как слитые перед слиянием вы можете предварительно посмотреть на изменения Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая так же используется в SVN. Создать новую метку с именем 1.0.0 можно выполнив 1b2e1d63ff это первые десять цифр уникального идентификатора (id) с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните Можно использовать меньшее количество символов в качестве идентификатора с учетом того что он является уникальным.
В случае если вы сделали что-то не то, вы можете заменить локальные изменения, используя команду git checkout -- произойдет замена изменений в вашем рабочем каталоге, на то что сейчас находится в HEAD. Изменения уже внесенные в индекс, так же как новые файлы будут сохранены. Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так встроенный в git графический интерфейс использовать цветной вывод в терминале выводить в логе коммит на одной строке интерактивный способ добавления в индекс
Git для профессионального программиста, это руководство по использованию Git в современных условиях. Git — распределенная система управления версиями — позволяет хранить много версий одного документа, при необходимости делать откат к более ранним, определять и контролировать изменения, разграничивать права и многие другие возможности.
Git стала популярной системой контроля версий для коммерческих разработок и для проектов с открытым исходным кодом. Эффективный и профессионально реализованный контроль версий необходим в любом коллективном веб-проекте. На данный момент Git используют большинство разработчиков свободно распространяемого ПО.
Появление огромного числа графических интерфейсов для всех платформ и поддержка IDE дает возможность внедрить Git в системы Windows. Это издание обновлено для Git-версии 2.0, еще больше в книге о GitHub.
1. Начало работы 19
Управление версиями 19
Локальные системы контроля версий 20
Централизованные системы контроля версий 20
Распределенные системы контроля версий 21
Краткая история Git 23
Основы Git 23
Снимки состояний, а не изменений 24
Локальность операций 25
Целостность Git 26
Git, как правило, только добавляет данные 26
Три состояния 26
Командная строка 28
Установка Git 28
Установка в Linux 29
Установка в Mac 29
Установка в Windows 30
Первая настройка Git 31
Ваш идентификатор 31
Выбор редактора 32
Проверка настроек 32
Получение справочной информации 33
Заключение 33
2. Основы Git 34
Создание репозитория в Git 34
Инициализация репозитория в существующей папке 34
Клонирование существующего репозитория 35
Запись изменений в репозиторий 36
Проверка состояния файлов 37
Слежение за новыми файлами 37
Индексация измененных файлов 38
Краткий отчет о состоянии 39
Игнорирование файлов 40
Просмотр индексированных и неиндексированных изменений 41
Фиксация изменений 43
Пропуск области индексирования 45
Удаление файлов 45
Перемещение файлов 47
Просмотр истории версий 47
Ограничение вывода команды log 52
Отмена изменений 54
Отмена индексирования 55
Отмена внесенных в файл изменений 56
Удаленные репозитории 57
Отображение удаленных репозиториев 57
Добавление удаленных репозиториев 58
Извлечение данных из удаленных репозиториев 59
Отправка данных в удаленный репозиторий 59
Просмотр удаленных репозиториев 60
Удаление и переименование удаленных репозиториев 61
Теги 61
Вывод списка тегов 62
Создание тегов 62
Теги с комментариями 62
Легковесные теги 63
Расстановка тегов постфактум 63
Обмен тегами 64
Псевдонимы в Git 65
Заключение 66
3. Ветвления в Git 67
Суть ветвления 67
Создание новой ветки 70
Смена веток 71
Основы ветвления и слияния 74
Основы ветвления 74
Основы слияния 78
Конфликты при слиянии 80
Управление ветками 82
Приемы работы с ветками 83
Долгоживущие ветки 84
Тематические ветки 85
Удаленные ветки 87
Отправка данных 91
Слежение за ветками 92
Получение данных с последующим слиянием 94
Ликвидация веток с удаленного сервера 94
Перемещение данных 94
Основы перемещения данных 94
Более интересные варианты перемещений 97
Риски, связанные с перемещением 99
Перемещение после перемещения 102
Сравнение перемещения и слияния 103
Заключение 104
4. Git на сервере 105
Протоколы 106
Локальный протокол 106
Протоколы семейства HTTP 107
Протокол SSH 110
Протокол Git 111
Настройка Git на сервере 111
Размещение на сервере голого репозитория 112
Простые настройки 113
Создание открытого ключа SSH 114
Настройка сервера 115
Git-демон 117
Интеллектуальный протокол HTTP 119
Интерфейс GitWeb 120
Приложение GitLab 122
Установка 122
Администрирование 123
Пользователи 124
Группы 124
Проекты 125
Хуки 126
Базовое применение 126
Совместная работа 126
Сторонний хостинг 127
Заключение 128
5. Распределенная система Git 129
Распределенные рабочие процессы 129
Централизованная работа 130
Диспетчер интеграции 131
Диктатор и помощники 132
Заключение 133
Содействие проекту 133
Рекомендации по созданию коммитов 134
Работа в маленькой группе 136
Маленькая группа с руководителем 142
Открытый проект, ветвление 146
Открытый проект, электронная почта 150
Заключение 153
Сопровождение проекта 153
Работа с тематическими ветками 153
Исправления, присланные по почте 154
Просмотр вносимых изменений 158
Интеграция чужих наработок 159
Схема с большим количеством слияний 162
Схема с перемещением и отбором 163
Программный компонент rerere 165
Идентификация устойчивых версий 165
Генерация номера сборки166
Подготовка устойчивой версии 167
Команда shortlog 167
Заключение 168
6. GitHub 169
Настройка и конфигурирование учетной записи 170
Доступ по протоколу SSH 170
Аватар 172
Адреса электронной почты 173
Аутентификация по двум признакам173
Содействие проекту 174
Ветвления проектов 175
Схема работы с GitHub 175
Запрос на включение 176
Стадии обработки запроса на включение 180
Более сложные запросы на включение 183
Язык разметки Markdown 188
GitHub-версия языка Markdown 188
Сопровождение проекта 193
Создание нового репозитория 193
Добавление соавторов 194
Управление запросами на включение 195
Упоминания и уведомления 201
Специальные файлы 204
Администрирование проекта 206
Управление организацией 207
Основные сведения об организации 207
Группы 208
Журнал регистрации 210
GitHub-сценарии 210
Хуки 211
API для GitHub 214
От пользователя Octokit 220
Заключение 220
7. Git-инструментарий 221
Выбор версии 221
Одна версия 221
Сокращения журнала ссылок 224
Диапазоны коммитов 226
Интерактивное индексирование 229
Индексирование файлов и его отмена 229
Индексирование изменений231
Скрытие и очистка 232
Скрытие вашей работы 233
Более сложные варианты скрытия 235
Отмена скрытых изменений 236
Создание ветки из скрытого фрагмента 236
Очистка рабочей папки 237
Подпись 238
Знакомство с GPG 239
Подпись тегов 239
Проверка тегов 240
Подпись коммитов 240
Подпись должна быть у всех 242
Поиск 242
Команда git grep 242
Поиск в Git-журнале 244
Поиск по строкам кода 244
Перезапись истории 245
Редактирование последнего коммита 246
Редактирование нескольких сообщений фиксации 246
Изменение порядка следования коммитов 248
Объединение коммитов 249
Разбиение коммита 250
Последнее средство: команда filter-branch 251
Команда reset 252
Три дерева 253
Рабочий процесс 254
Роль команды reset259
Команда reset с указанием пути 263
Объединение коммитов 265
Сравнение с командой checkout 267
Заключение 269
Более сложные варианты слияния 269
Конфликты слияния 270
Прерывание слияния 272
Игнорирование пробелов 272
Слияние файлов вручную 273
Применение команды checkout 276
Протоколирование слияния 277
Комбинированный формат 278
Отмена результатов слияния 280
Другие типы слияния 284
Команда rerere 287
Отладка с помощью Git 292
Примечания к файлам 293
Двоичный поиск 294
Подмодули 296
Начало работы 296
Клонирование проекта с подмодулями 298
Работа над проектом с подмодулями 300
Публикация результатов редактирования подмодуля 305
Слияние результатов редактирования подмодуля 306
Полезные советы309
Пакеты 313
Замена 316
Хранение учетных данных 322
Взгляд изнутри 323
Нестандартный вариант хранения учетных данных 325
Заключение 327
8. Настройка системы Git 328
Конфигурирование системы Git 328
Основные настройки на стороне клиента 329
Цвета в Git 331
Внешние инструменты для слияния и индикации изменений 332
Форматирование и пробелы 336
Настройка сервера 338
Git-атрибуты 339
Бинарные файлы 339
Развертывание ключа 342
Экспорт репозитория 345
Стратегии слияния 346
Git-хуки 347
Установка хука 347
Хуки на стороне клиента 347
Хуки для работы с коммитами 347
Хуки для работы с электронной почтой 348
Другие клиентские хуки 349
Хуки на стороне сервера 350
Пример принудительного внедрения политики 351
Хук на стороне сервера 351
Формат сообщения фиксации 352
Система контроля доступа пользователей 353
Тестирование 356
Хуки на стороне клиента 357
Заключение 360
9. Git и другие системы контроля версий 361
Git в качестве клиента 361
Git и Subversion 362
Git и Mercurial 372
Краткое содержание 13
Git и Perforce 380
Git и TFS 394
Переход на Git 404
Subversion 404
Mercurial 406
Perforce 408
TFS 410
Другие варианты импорта 411
Заключение 417
10. Git изнутри 418
Канализация и фарфор 419
Объекты в Git 420
Объекты-деревья 421
Объекты-коммиты 424
Хранение объектов 427
Ссылки в Git 428
Указатель HEAD 429
Теги 430
Удаленные ветки 431
Pack-файлы 432
Спецификация ссылок 435
Спецификация ссылок для отправки данных на сервер 437
Ликвидация ссылок 437
Протоколы передачи данных 438
Простой протокол 438
Интеллектуальный протокол 440
Обслуживание репозитория и восстановление данных 444
Обслуживание репозитория 444
Восстановление данных 445
Удаление объектов 447
Переменные среды 451
Глобальное поведение 451
Расположение репозитория 451
Пути доступа 452
Фиксация изменений 453
Работа в сети 453
Определение изменений и слияние 454
Отладка454
Разное 456
Заключение 457
Приложение A. Git в других средах 458
Графические интерфейсы 458
Утилиты gitk и git-gui 459
GitHub-клиенты для Mac и Windows 461
Подводя итоги 464
Другие GUI 464
Git в Visual Studio 465
Git в Eclipse 466
Git в Bash 466
Git в Zsh 468
Git в Powershell 469
Заключение 470
Приложение Б. Встраивание Git в приложения 471
Командная строка 471
Libgit2 472
Нетривиальная функциональность 474
Другие привязки 476
Приложение В. Git-команды 478
Настройка и конфигурирование 478
Копирование и создание проектов479
Фиксация состояния 480
Ветвления и слияния 483
Совместная работа и обновление проектов 486
Проверка и сравнение 489
Отладка 490
Исправления 490
Электронная почта 491
Внешние системы 492
Администрирование493
Служебные команды 494
Об авторах 495
Git программирование. Видео
Шпаргалка по git. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.
Git – это распределенная система контроля версий. Это главное отличие git от svn. Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.
В рамках этого репозитория можно делать все тоже самое, что и обычно в svn – создавать ветки, просматривать изменения, выполнять коммиты. Для того, чтобы можно было работать с удаленными репозиториями и обмениваться изменениями с другими разработчиками, в git есть две команды, не имеющие аналогов в svn – git push и git pull .
git push – вливание локальных изменений в удаленный репозиторий. git pull – вливание изменений из удаленного репозитория в локальный. Обмен данными обычно происходит с использованием протокола SSH.
Git поддерживают несколько крупных репозиториев – GitHub. SourceForge. BitBucket и Google Code. Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.
Изображение с сайта http://www.stickycomics.com/where-did-you-meet/
Ниже приведены инструкции по использованию git в различных ситуациях. Что делать, если нужно создать новый репозиторий, или выписать ветку, и т.п. Я использую подобную шпаргалку для скоростного копипаста :) Чтобы не отвлекаться, когда голова занята сложными задачами. По мере создания новых инструкций, статья будет обновляться.
Пошаговые рекомендации Как выписать репозиторий с github> git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.
можно и не один, а много коммитов перечислить через проблел
пример: git cherry-pick qw1w2e3 a4s5d5 f6g7h8j8
(последний коммит будет верхним)
У меня с гитом было так…
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.
Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.
Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.
Опять же статьи описывают не все, а книга Чакона – все и сразу. Очень здоровская книга и ее перевели на русский уже.
Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только…). Потом я забыл ее на работе (( – я ж уволился сразу как дочитал все книги xD.
проконсультируйте пжл что я делаю не правильно.
#!/bin/bash
clear
git status | grep -c “nothing to commit”
read $s
echo $s
echo выводит null
Простите, у меня сейчас нет git на серверах – т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. (
You should remove $ in fourth line:)
Try smth like that:
#!/bin/bash
clear
git status | grep -c “nothing to commit”
read s
echo $s
Что значит выписать? Все татары кроме я.
