Git — SmartGit-гит репозитории


Содержание

.5 Основы Git — Работа с удалёнными репозиториями

Работа с удалёнными репозиториями

Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push) и получение (pull) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.

Отображение удалённых репозиториев

Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote . Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали:

Чтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v :

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

Это означает, что мы легко можем получить изменения от любого из этих пользователей. Но, заметьте, что origin — это единственный удалённый сервер прописанный как SSH-ссылка, поэтому он единственный, в который я могу помещать свои изменения (это будет рассмотрено в главе 4).

Добавление удалённых репозиториев

В предыдущих разделах мы упомянули и немного продемонстрировали добавление удалённых репозиториев, сейчас мы рассмотрим это более детально. Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url] :

Теперь вы можете использовать в командной строке имя pb вместо полного URL. Например, если вы хотите извлечь (fetch) всю информацию, которая есть в репозитории Павла, но нет в вашем, вы можете выполнить git fetch pb :

Ветка master Павла теперь доступна локально как pb/master . Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.

Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

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

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если у вас есть ветка, настроенная на отслеживание удалённой ветки (для дополнительной информации смотри следующий раздел и главу 3), то вы можете использовать команду git pull . Она автоматически извлекает и затем сливает данные из удалённой ветки в вашу текущую ветку. Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: git push [удал. сервер] [ветка] . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование, как правило, настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки наработок на сервер:

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push. Смотри главу 3 для более подробного описания, как отправлять (push) данные на удалённый сервер.

Инспекция удалённого репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [удал. сервер] . Если вы выполните эту команду с некоторым именем, например, origin , вы получите что-то подобное:

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации, и наверняка вы встретились с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере. И для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .

Удаление и переименование удалённых репозиториев

Для переименования ссылок в новых версиях Git’а можно вылолнить git remote rename , это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul , вы можете сделать это следующим образом:

Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как pb/master , стало paul/master .

Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm :

2. Основы работы с Git¶

Введение¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

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

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

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

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

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

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

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

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

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

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

-s – понимать стандартные папки SVN (trunk, branches, tags)

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с локальным репозиторием¶

Базовые команды¶

git init — создание репозитория

Команда git init создает в директории пустой репозиторий в виде директории .git , где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add . Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

индексация измененного файла, либо оповещение о создании нового:

внести в индекс все изменения, включая новые файлы:

Из индекса и дерева проекта одновременно файл можно удалить командой git rm :

хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

внести в индекс все удаленные файлы:

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

сбросить весь индекс:

удалить из индекса конкретный файл:

Команда git reset используется не только для сбрасывания индекса, поэтому дальше
ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

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

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
файлы, игнорируемые git.

git commit — совершение коммита

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

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

Есть несколько ключей, упрощающих работу с git commit :
совершит коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено.
комментируем коммит прямо из командной строки вместо текстового редактора.
внесет в индекс и создаст коммит на основе изменений единственного файла.

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом —soft ) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

  1. git commit — некорректный коммит
  2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
  3. edit WRONGFILE
  4. edit ANOTHERWRONGFILE
  5. git add .
  6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ —hard ) — команда, которую следует использовать с
осторожностью. git reset —hard вернет дерево проекта и индекс в состояние,
соответствующее указанному коммиту, удалив изменения последующих коммитов:

Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяем коммит, помеченный тегом:

Отменяем коммит, используя его хэш:

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


git log — разнообразная информация о коммитах в целом

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

Простейший пример использования, в котором приводится короткая справка по всем
коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
подробно узнать можно ниже, в разделе «Ветвления и слияния»):

Получить подробную информацию о каждом в виде патчей по файлам из коммитов
можно, добавив ключ -p (или -u):

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
строк, удаленных файлов вызывается ключом —stat :

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
—summary :

Цукерберг рекомендует:  React js - Ваше мнение о сайте на MeteorReactJS

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):

или, если версия git не совсем свежая:

Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):

изменения, касающиеся отдельной папки:

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1:

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

Интересные возможности по формату вывода команды предоставляет ключ —pretty .

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

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

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

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

Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
—graph .

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff ,
определяющую изменения между объектами в проекте — деревьями (файлов и
директорий).

Показать изменения, не внесенные в индекс:

Изменения, внесенные в индекс:

Изменения в проекте по сравнению с последним коммитом:

Можно сравнивать «головы» веток:

или активную ветку с какой-либо:

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show :

git blame и git annotate — команды, помогающие отслеживать изменения файлов

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

Можно указать и конкретные строки для отображения:

Аналогично работает команда git annotate , выводящая и строки, и информацию о
коммитах, их коснувшихся:

git grep — поиск слов по проекту, состоянию проекта в прошлом

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

Поиск слова tst в проекте:

Подсчитать число упоминаний tst в проекте:

Поиск в старой версии проекта:

Команда позволяет использовать логическое И и ИЛИ.

Найти строки, где упоминаются и первое слово, и второе:

Найти строки, где встречается хотя бы одно из слов:

Ветвление¶

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:

Просто перечислить существующие ветки, отметив активную:

Создать новую ветку new-branch:

Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

Удалить ветку в любом случае:

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

git checkout — переключение между ветками, извлечение файлов


Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

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

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

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

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Вернуть somefile к состоянию последнего коммита:

Вернуть somefile к состоянию на два коммита назад по ветке:

git merge — слияние веток (разрешение возможных конфликтов)

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

Попробовать объединить текующую ветку и ветку new-feature:

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE , что можно увидеть в git status .

Произошла неудачная попытка слияния:

Смотрим на проблемные места:

Индексируем наши изменения, тем самым снимая метки:

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

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

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

git rebase — построение ровной линии коммитов

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

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

Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

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

на master накладывается активная в настоящий момент ветка:

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase —continue . Альтернативными выходами будут команды git rebase —skip (пропустить наложение коммита и перейти к следующему) или git rebase —abort (отмена работы команды и всех внесенных изменений).

С ключом -i ( —interactive ) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

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

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита

Прочие команды и необходимые возможности¶

Хэш — уникальная идентификация объектов

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

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

найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

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

Иногда хватает и четырех символов:

Читаем лог с коммита по коммит:

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

Пометить определенный коммит:

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

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff , git log и так далее:

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

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

Создать обычный тэг, сразу указав в качестве аргумента комментарий:


Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

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

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

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

что привнес «дедушка» нынешнего коммита:

Обозначения можно объединять, чтобы добраться до нужного коммита:

файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status . Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

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

Пример содержимого такого файла:

Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore .

Серверные команды репозитория¶

; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.

Рецепты¶

Создание пустого репозитория на сервере

Импорт svn репозитория на Git-сервер

Пошаговая инструкция по работе с git и github для студентов

В первую очередь надо установить клиент git: обязательно потребуется консольный клиент, доступный по ссылке http://git-scm.com/downloads (поддерживаются основные ОС), графический клиент можно установить по желанию, исходя из своих предпочтений. На Unix системах можно воспользоваться менеджером пакетов (yum на fedora и подобных или apt-get на debian, ubuntu и подобных) вместо того, чтобы скачивать установщик с сайта.

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

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

Аккаунт и репозитории на github.com

Затем надо зарегистрироваться на https://github.com/. После чего можно будет создавать свои репозитории или присоединиться к работе над проектами коллег, сделав fork другого репозитория. Вам предлагается начать с создания fork-а к заведенному мной репозиторию https://github.com/andreiled/mipt-cs-4sem, где я буду выкладывать примеры кода к занятиям и задания. О механизме обмена кодом между пользователями мы поговорим на следующем занятии.

Работа с кодом из репозитория на локальном компьютере

Создание локального репозитория, связанного с удаленным репозиторием

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

  1. Открываем консольный клиент.
  • На Windows после установки клиента появляется пункт Git Bash в контекстом меню папки. Достаточно перейти в желаемую папку и воспользоваться этим пунктом меню.
  • На Unix системах достаточно открыть терминал и перейти в нужную директорию. При стандартной установке консольного клиента будет доступна команда git без дополнительных усилий.
  1. Выполняем команду git clone https://github.com/%user_login%/%repo_name%.git . Полную https ссылку на репозиторий для его выкачивания можно также найти на странице самого репозитория на github. После этого в текущей папке появится новая папка с именем %repo_name% , содержащая копию удаленного (remote) репозитория.
  2. Переходим в свежесозданную папку репозитория и настраиваем его:
  3. git config user.name ivan.ivanov
  4. git config user.email ivanov@example.com

Внесение и оформление изменений в локальном репозитории

  1. Воспользовавшись командой git status можно узнать, на какой ветке (branch) репозитория вы сейчас находитесь, какие изменения присутствуют в вашей рабочей копии и другую информацию.
    Рабочей копией называется совокупность файлов в локальной папке репозитория за исключением служебных файлов.
  2. После внесения каких-либо изменений в рабочую копию их можно закоммитить в локальный репозиторий:
  3. сначала нужная часть изменений подготавливается к коммиту с использованием команды git add %file_path%
  4. после чего производится коммит командой git commit
    Использование команды без аргументов откроет текстовый редактор, где надо будет написать комментарий для коммита, коммит обязательно должен иметь комментарий. Другим вариантом задания комментария к коммиту является использование команды git commit -m «%commit_message%»
  5. Историю изменений можно посмотреть командой git log или git log —name-only . Если вся история изменений не умещается на экране, то можно пользоваться клавишами прокрутки на клавиатуре («стрелочки», PgUp, PgDown), выход из режима просмотра изменений осуществляется нажатием клавиши «q».

Загрузка локальных изменений в удаленный репозиторий


После того, как были выполнены нужные локальные коммиты, изменения можно загрузить в удаленный репозиторий с помощью команды git push origin master . GIT клиент при этом запросит имя пользователя и пароль для доступа к github.
Выполнение этой команды может закончиться с ошибкой, если в локально репозитории отсутствуют последние изменения, имеющиеся в удаленном репозитории. Для решения этой проблемы надо выполнить команду git pull , которая скачает последние изменения из удаленного репозитория и смержит их с вашими локальными правками, после чего можно повторить команду git push .

Знакомство с Git и GitHub: руководство для начинающих

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цукерберг рекомендует:  Ускоренная верстка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Git — SmartGit-гит репозитории

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

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

М аленький план того, что мы будем делать:

  1. Создание репозитория на Bitbucket и клонирование репозитория (добавление его в SmartGit).
  2. Создание комитов.
  3. Отмена изменений.
  4. Создание веток.
  5. Проталкивание веток на удаленный репозиторий (аплоад веток на удаленный сервер).
  6. Слияние веток.

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

Запустим SmartGit, выберем «Project» — «Clone» (или Ctrl + Alt + O) и заполним необходимые поля:

Система запросит ваш логин и пароль от Bitbucket:

В следующем окне доступны две опции клонирования «Include Submodules» и «Fetch all Heads and Tags». Git позволяет отдельные модули приложения хранить в разных репозиториях. Если вы отметите опцию «Include Submodules» — SmartGit автоматически подгрузит все модули. Если отметить опцию «Fetch all Heads and Tags», то SmartGit после создания папки проекта скачает все ветки и теги для данного репозитория:

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

Сохранение измений (т.е. создание коммита)


Идем дальше. Создадим комит. Что такое комит? Это фиксация изменений. Каждый комит «запоминает» что именно вы изменили и в любой момент времени можно вернуть прежнее состояние файлов. Советую вам после каждого значимого изменения, например, исправление бага в функции, делать комит. Что бы создать комит, нужно что-то изменить в проекте. Добавьте парочку файлов в папку с проектом:

Теперь можно увидеть изменения нашего проекта в SmartGit:

Выберем оба файла и нажмем сначала «Stage», а потом «Commit». Зачем нужно нажимать «Stage»? Кнопка «Stage» добавляет в текущий индекс выбранные файлы. Если вы хотите создать комит для двух файлов, а изменили, предположим целых 5, достаточно выбрать эти два файла, нажать «Stage», что добавит их в индекс, а после «Commit». Таким образом только выбранные два файла попадут в комит.

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

После чего следует нажать кнопку «Commit». Кнопка «Commit & Push» делает тоже самое, но еще и проталкивает (заливает) изменения в удаленный репозиторий (в нашей случае это Bitbucket). Пока не стоит этого делать. Проталкиванием мы займемся далее. Внизу, в списке веток, появится локальная ветка «master». Это основная ветка кода приложения. Что такое ветки, расскажу чуть позже.

А сейчас сделаем что-нибудь с нашим проектом, а потом откатим изменения. Я удалю файл readme.txt, отредактирую файл index.php и добавлю новый файл confic.cfg и сделаю коммит.

А теперь откатим изменение после комита. Зайдем в Log:

Выберем комит, к которому хотим откатиться и нажмем «Reset»:

В следующем окне нам предлагают выбрать какой именно «Reset» мы хотим сделать:

Объясню. Вспомните, что при создании комита, вы сначала добавляете файлы в индекс (stage). Это позволяет закомитить только проиндексированные файлы. Soft reset сбрасывает только комиты. Индекс и физические изменения в файлах остаются. Mixed reset работает так же, как и софт, но еще удаляет индекс файлов. Hard reset удаляет комиты, индекс и физические изменения в файлах. Аккуратно используйте hard reset, что бы нечаянно не удалить лишнего.

Я сделал hard reset для наглядности:

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

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

Теперь немного о создании веток. Зачем они вообще нужны? Ветка позволяет сохранить текущее состояние кода и безопасно экспериментировать с изменениями в коде. Например, вы пишите новый модуль. Логично делать это в отдельной ветке. Звонит начальство и говорит, что в проекте баг и срочно нужно пофиксить, а у вас модуль не дописан. Как же заливать нерабочие файлы? Просто переключитесь на рабочую ветку без модуля, пофиксите баг и заливайте файлы на сервер. А когда «опасность» миновала — продолжите работу над модулем. И это один из многих примеров пользы веток.

Попробуем создать свою ветку. У нас уже одна есть, это master. Она создается автоматически (если отсутствует) когда вы делаете первый комит. Создадим еще одну ветку и назовем ее «new_future1». Нажмите F7 или правым кликом внизу во вкладке «Branches» на надпись «Local Branches» и в выпадающем списке выберите «Add branch»:

Нажмите «Add branch & Switch» что бы сразу переключиться на созданную ветку. Теперь вы можете создавать новые комиты, изменять файлы и не беспокоиться. Так как у вас всегда есть ветка мастер, в которую можно вернуться. Когда вы переключаете ветку, Git меняет локальные файлы на те, которые есть в этой ветке. То есть, если вы создадите новую ветку поменяете что-то в файле index.php, а потом переключитесь на ветку master то все изменения, произведенные вами будут удалены. Если же переключиться обратно в созданную ветку — изменения вернутся.

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

До сих пор мы работали локально. Попробуем залить труды нашей работы на сервер. Создадим какой-нибудь комит в ветке new_future1. В случае если репозитарий пуст, а он пуст, так как мы создали его некоторое время назад и на сервер ничего не залили, Bitbucket основной назначает ту ветку, которую залили первой. Поэтому переключимся на ветку «master» и нажмем кнопку «Push»:

. Картинка «Кнопка Push SmartGIt» .

Дальше SmartGit спросит настроить ли отслеживание ветки (cofigure tracking). Отслеживание позволяет автоматически обновлять соответствующие ветки, когда вы скачиваете или загружаете обновления кода. Поэтому смело жмите «Configure»:

Теперь переключитесь на другую ветку и проделайте тоже самое. Зайдем на Bitbucket и посмотрим, что изменилось в разделе «Commits»:

Как видите все попало на удаленный сервер.

Теперь сольем ветки. Зачем это нужно? Возьмем тот же пример с модулем. Рано или поздно вы допишите его и вам нужно будет добавить код модуля в основной код приложения. Достаточно просто слить ветки. Для этого переключитесь на ветку, в которую хотите слить код. В нашем случае это мастер. После чего нажмите правым кликом на ветку, с которой хотите слить код и выберите «Merge»:

Дальше SmartGit спросит каким именно образом нужно слить ветки. Выберите «Create Merge-Commit».

А теперь осталось протолкнуть изменения ветки master на сервер. Заливаем изменение на сервер так же, как мы делали это раньше и получаем:

Вот и все на этот раз. Из-за картинок статья вышла большой. Задавайте свои ответы. Пишите вопросы.

Как работать с Git-репозиториями. Создаём и коммитим

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

Цукерберг рекомендует:  Javascript - Нужна помощь

Есть возможность создавать только публичные (доступные всем пользователям) репозитории. Для создания приватных – придётся доплатить. Но мы приверженцы Open Source, поэтому будем создавать публичные.

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

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

Перед нами главное окно программы: Главное окно Smartgit

Слишком много непонятного. Рассмотрим по ходу дела. Итак, добавим наш ранее заготовленный репозиторий в программу. Для этого в главном меню программы выбираем Repository -> Add or Create: Добавляем репозиторий

Указываем локальный каталог для хранения файлов репозитория: Указываем каталог хранения

Теперь укажем, с каким удалённым репозиторием будем синхронизироваться. Для этого перейдём в меню на пункт Remote -> Add Добавляем удалённый репозиторий

В появившемся окне нажимаем кнопку хостинг-провайдера и выбираем github.com:

К слову, бывают и другие:

  • Assembla
  • Beanstalk
  • Bitbucket
  • Codebase
  • Unfuddle

Хостинг-провайдер

Мы получим все удалённые репозитории, зарегистрированные на нашем аккаунте. Наши репозитории

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

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

Перейдя в программу Smartgit мы увидим, что в окне файлов появился index.php, а справа внизу – его содержимое. Файл имеет статус Untracked (отсутствует в репозитории). Появился наш первый файл

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

Теперь у нас начинает вестись своеобразная история изменений проекта, но пока что она только локальная. Для того, чтобы закачать все изменения проекта на сервер github.com (в удалённый репозиторий), нужно нажать кнопку Push. Там мы указываем какую “ветку” проекта будем закачивать. К веткам мы вернёмся позже, а пока оставим основную (master) Push основной ветки

Теперь проект обновился и на github.com! Проект на github.com

Вот примерно таким образом и ведётся разработка. Внесём некоторые изменения в файл index.php: тут же в программе отобразится разница между файлами и статус файла сменится на Modyfied (изменён). Ниже можно увидеть разницу, красная строка – изменения/удаление, зелёная – добавление. Таким образом будет сохраняться история развития проекта и, если мы освоим ведение различных веток, возможен будет откат на предыдущую/параллельную версию. Но мы к этому вернёмся. Изменяем файл проекта

А теперь представим, что наш коллега хочет приобщиться к прекрасному (нашему проекту).

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

Лучшие клиенты Git GUI для Windows


Лучшие клиенты Git GUI для Windows

Git — это, несомненно, самая используемая система контроля версий. Собрал некоторые из лучших клиентов Git GUI, доступных для операционной системы Windows.

Клиенты Git GUI для Windows:

1. GitHub Desktop

Рабочий стол GitHub в основном является расширением рабочего процесса GitHub. Вы можете войти в систему, используя свои учетные данные GitHub и начать работу с вашими репозиториями. Есть возможность создавать новые репозитории, добавлять локальные репозитории и выполнять большинство операций Git из пользовательского интерфейса. GitHub Desktop является полностью открытым исходным кодом, и он доступен для MacOS и Windows. Нажмите здесь, чтобы загрузить GitHub Desktop.

2. GitKraken

GitKraken — это независимый разработчик Git для Windows. Он поддерживает GitHub, Bitbucket и Gitlab. GitKraken доступен в бесплатных, премиальных и корпоративных вариантах. Бесплатная версия подходит для небольших команд и стартапов, но вам может потребоваться обновиться после того, как ваша команда и работа будут расширяться. Перед использованием этого инструмента вам необходимо зарегистрироваться на сайте. Нажмите здесь, чтобы скачать GitKraken.

3. SmartGit

SmartGit — отличный клиент Git профессионального уровня, который можно использовать для некоммерческих организаций. Вы можете свободно использовать его для разработки open-source и бесплатного программного обеспечения. Но вам может потребоваться приобрести лицензию, если вы собираетесь использовать этот инструмент для коммерческих целей. SmartGit охватывает все функции Git и поставляется со всеми функциями для совместной работы. Инструмент даже поддерживает создание pull-запросов на GitHub. Нажмите здесь, чтобы загрузить SmartGit.

4. SourceTree

SourceTree — бесплатный клиент Git, разработанный Atlassian, компанией, стоящей за Jira и Bitbucket. Этот бесплатный клиент Git показывает огромную поддержку репозиториев, размещенных Bitbucket и GitHub. Перед использованием SourceTree вам необходимо создать учетную запись Atlassian. Нажмите здесь, чтобы загрузить SourceTree.

Итак, это были некоторые из клиентов Git, которые я использовал и нашел полезными. Если вы просто новичок, я бы рекомендовал использовать такой инструмент, как GitHub Desktop или Source Tree. И если вы опытный разработчик, идите на GitKraken и Smart Git.

Спасибо, что читаете! Подписывайтесь на мой канал в Telegram и Яндекс.Дзен. Только там последние обновления блога и новости мира информационных технологий.

Респект за пост! Спасибо за работу!

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

На данный момент есть возможность поддержать меня через Яндекс Деньги:

И PayPal. Спасибо! Все собранные средства будут пущены на развитие сайта. Поддержка проекта является подарком владельцу сайта.

How do I remove a repository from SmartGit?

How do I remove a local repository from SmartGit v7?

If I delete the repository from disk it still appears in my list of repositories but with after it.

I cannot see any way of removing it from the UI.

3 Answers 3

Right click on the repo and choose «Remove» item. Note that you have to close the repo to be able to do this. One way to close the repo is to right click on it and choose «Close» item. Another way is to open a different repo.

delete the .git folder and it will remove it

Actually I just figured it out. codeWizard was almost there, deleting it from disk was the correct solution, but I needed to restart smartgit.

On restart smartGit asks if I want to remove any missing repositories. There doesn’t appear to be a way of doing this without restarting the program.

Три графических клиента Git для Linux

Оригинал: Three Graphical Clients for Git on Linux
Автор(ы): Jack Wallen
Дата публикации: 27 июля 2020 года
Перевод: А. Кривошей
Дата перевода: февраль 2020 года

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

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

Предупреждение: не все эти утилиты бесплатны, а некоторые выпускаются под проприетарными лицензиями. Тем не менее, все они достаточно хорошо работают на платформе Linux и делают взаимодействие с GitHub более быстрым и удобным.

SmartGit

SmartGit — это проприетарная утилита, бесплатная для некоммерческого использования. Если вы планируете использовать SmartGit в коммерческой среде, стоимость лицензии составляет 99 долларов США в год за одну лицензию или 5,99 долларов США в месяц. Существуют и другие редакции (например, Distributed Reviews и SmartSynchronize), стоимость которых составляет 15 долларов США за лицензию. Вы можете скачать исходный код или пакет .deb для установки. Я тестировал SmartGit в Ubuntu 18.04, и он работал без проблем.

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

После установки SmartGit я подключил его к своей личной учетной записи GitHub за считанные секунды. Панель инструментов делает работу с хранилищем невероятно простой. Push, pull, check-out, merge, добавление веток, cherry pick, revert, rebase, reset — все самые популярные функции Git здесь присутствуют. Помимо поддержки большинства стандартных функций Git и GitHub, SmartGit очень стабилен. По крайней мере, когда вы используете утилиту в Ubuntu, вы чувствуете, что работаете с приложением, специально разработанным для Linux.

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

GitKraken

GitKraken — это еще один проприетарный инструмент с графическим интерфейсом, который делает работу с Git и GitHub незабываемой. Там, где SmartGit предлагает очень упрощенный пользовательский интерфейс, GitKraken имеет красиво оформленный интерфейс, который предлагает немного больше возможностей из коробки. Доступна бесплатная версия GitKraken (и вы можете протестировать полноценную платную версию с 15-дневным пробным периодом). После окончания пробного периода вы можете продолжать пользоваться бесплатной версией, но только для некоммерческого использования.

Для тех, кто хочет получить максимальную отдачу от своего процесса разработки, именно GitKraken может стать наилучшим выбором. Этот конкретный подход к графическому интерфейсу Git включает в себя такие визуальные имнструменты, как графы коммитов, перетаскивание, бесшовную интеграцию (с GitHub, GitLab и BitBucket), простые задачи в приложении, инструменты слияния в приложении, нечеткий поиск, поддержка gitflow, отмена и повтор в 1 клик, горячие клавиши, история файлов, подмодули, светлые и темные темы, поддержка git hooks, git LFS и многое другое. Но одна особенность, которую многие пользователи оценят больше всего, — это невероятно хорошо продуманный интерфейс.

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

— $49 в год для частного лица
— $39 на пользователя в год для 10+ пользователей
— $29 на пользователя в год для 100+ пользователей

Учетные записи Pro позволяют вам использовать как Git Client, так и Glo Boards (которые являются инструментом управления проектами GitKraken) в коммерческих целях. Glo Boards — это особенно интересная функция, поскольку они позволяют синхронизировать вашу Glo Board с GitHub Issues. Glo Boards являются расшариваемыми и включают поиск и фильтры, отслеживание проблем, поддержку markdown, вложения файлов, @mentions, card checklists и многое другое. Все это можно делать из графического интерфейса GitKraken. GitKraken доступен для Linux в виде файла .deb или исходного кода.

Git Cola

Git Cola — это бесплатная программа с открытым исходным кодом в нашем списке. В отличие от GitKraken и Smart Git, Git Cola представляет собой довольно простой Git-клиент. Git Cola написана на Python с интерфейсом GTK, поэтому независимо от того, какую комбинацию дистрибутива и десктопа вы используете, она должна легко интегрироваться. А поскольку она с открытым исходным кодом, вы должны найти ее в менеджере пакетов вашего дистрибутива. Таким образом, установка — это не что иное, как открытие магазина приложений вашего дистрибутива, поиск «Git Cola» и установка. Вы также можете установить программу из командной строки:

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

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

— несколько подкоманд;
— пользовательские настройки окна;
— настраиваемые переменные среды;
— языковые настройки;
— пользовательские настройки графического интерфейса;
— горячие клавиши.

Хотя Git Cola поддерживает подключение к удаленным репозиториям, интеграция с Github не так интуитивна, как в GitKraken или SmartGit. Но если вы выполняете большую часть своей работы локально, Git Cola — выдающийся инструмент, который не встанет между вами и Git.

Git Cola также поставляется с усовершенствованным визуализатором DAG (Directed Acyclic Graph), который называется Git Dag. Этот инструмент позволяет получить визуальное представление ваших ветвей. Git Dag запускается либо отдельно от Git Cola, либо в Git Cola из пункта меню View > DAG. Git DAG — очень мощный инструмент, который позволяет Git Cola считаться одним из лучших графических интерфейсов Git с открытым исходным кодом на рынке.

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

Записки программиста

Моя шпаргалка по работе с Git

28 декабря 2011

Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличие от GitHub, BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

  • Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
  • Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
  • Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
  • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
  • Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
  • Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
  • Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
  • Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
  • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
  • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Пример использования Git

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее:

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих