Git gui что это

Возможности [ править | править код ]

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

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

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

Особенности реализации [ править | править код ]

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

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

По умолчанию репозиторий хранится в подкаталоге с названием «.git» в корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории. Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория из корневого каталога этого дерева (или указав корневой каталог в параметрах программы). Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создаётся рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).

Архитектура [ править | править код ]

Нижний уровень git является так называемой контентно-адресуемой файловой системой. Инструмент командной строки git содержит ряд команд по непосредственной манипуляции этим репозиторием на низком уровне. Эти команды не нужны при нормальной работе с git как с системой контроля версий, но нужны для реализации сложных операций (ремонт повреждённого репозитория и так далее), а также дают возможность создать на базе репозитория git своё приложение.

Для каждого объекта в репозитории вычисляется SHA-1-хеш, и именно он становится именем файла, содержащего данный объект в каталоге .git/objects. Для оптимизации работы с файловыми системами, не использующими деревья для каталогов, первый байт хеша становится именем подкаталога, а остальные — именем файла в нём, что снижает количество файлов в одном каталоге (ограничивающий фактор производительности на таких устаревших файловых системах).

Все ссылки на объекты репозитория, включая ссылки на один объект, находящийся внутри другого объекта, являются SHA-1-хешами.

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

В классическом обычном сценарии в репозитории git есть три типа объектов — файл, дерево и «коммит» (англ. commit — фиксация). Файл есть какая-то версия какого-то пользовательского файла, дерево — совокупность файлов из разных подкаталогов, «коммит» — дерево и некая дополнительная информация (например, родительские коммиты, а также комментарий).

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

Репозиторий Git бывает локальный и удалённый. Локальный репозиторий — это подкаталог .git, создаётся (в пустом виде) командой git init и (в непустом виде с немедленным копированием содержимого родительского удалённого репозитория и простановкой ссылки на родителя) командой git clone.

Практически все обычные операции с системой контроля версий, такие, как коммит и слияние, производятся только с локальным репозиторием. Удалённый репозиторий можно только синхронизировать с локальным как «вверх» ( push ), так и «вниз» ( pull ).

Наличие полностью всего репозитория проекта локально у каждого разработчика даёт Git ряд преимуществ перед SVN. Так, например, все операции, кроме push и pull, можно осуществлять без наличия интернет-соединения.

Очень мощной возможностью git являются ветви, реализованные куда более полно, чем в SVN: по сути, ветвь git есть не более чем именованная ссылка, указывающая на некий коммит в репозитории (используется подкаталог refs). Коммит без создания новой ветви всего лишь передвигает эту ссылку на себя, а коммит с созданием ветви — оставляет старую ссылку на месте, но создаёт новую на новый коммит, и объявляет её текущей. Заменить локальные девелоперские файлы на набор файлов из иной ветви, тем самым перейдя к работе с ней — так же тривиально.

Также поддерживаются субрепозитории с синхронизацией текущих ветвей в них.

Команда push передаёт все новые данные (те, которых ещё нет в удалённом репозитории) из локального репозитория в репозиторий удалённый. Для исполнения этой команды необходимо, чтобы удалённый репозиторий не имел новых коммитов в себя от других клиентов, иначе push завершается ошибкой, и придётся делать pull и слияние.

Команда pull — обратна команде push. В случае, если одна и та же ветвь имеет независимую историю в локальной и в удалённой копии, pull немедленно переходит к слиянию.

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

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

Кроме слияния, Git поддерживает ещё операцию перемещения (англ. rebase ). Эта операция есть получение набора всех изменений в ветви А, с последующим их «накатом» на ветвь B. В результате ветвь B продвигается до состояния AB. В отличие от слияния, в истории ветви AB не останется никаких промежуточных коммитов ветви A (только история ветви B и запись о самом rebase, это упрощает интеграцию крупных и очень крупных проектов).

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

Имя ветви по умолчанию: master. Имя удалённого репозитория по умолчанию, создаваемое git clone во время типичной операции «взять имеющийся проект с сервера себе на машину»: origin.

Таким образом, в локальном репозитории всегда есть ветвь master, которая есть последний локальный коммит, и ветвь origin/master, которая есть последнее состояние удалённого репозитория на момент завершения исполнения последней команды pull или push.

Команда fetch (частичный pull) — берёт с удалённого сервера все изменения в origin/master, и переписывает их в локальный репозиторий, продвигая метку origin/master.

Если после этого master и origin/master разошлись в стороны, то необходимо сделать слияние, установив master на результат слияния (команда pull есть fetch+merge). Далее возможно сделать push, отправив результат слияния на сервер и установив на него origin/master.

Детали реализации в Windows [ править | править код ]

В Windows-версии (официальная Windows-версия называется mSysGit) используется пакет mSys — порт POSIX-совместимой командной строки под Windows из проекта MinGW. Под mSys перенесены все необходимые для Git библиотеки и инструменты, а также сам Git. При работе с удалёнными репозиториями по протоколу SSL используется хранилище сертификатов из mSys, а не из Windows.

Существует немало графических оболочек для Git для Windows, например, TortoiseGit. Все они реализованы через вызовы mSysGit и требуют его установки на машину. Не исключение и SourceTree, решение компании Atlassian, но mSysGit оно содержит внутри себя, что имеет свои плюсы и минусы (так установка в глубокий подкаталог затрудняет добавление в mSys нужных SSL-сертификатов).

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

Сетевые возможности и серверные решения [ править | править код ]

Git использует сеть только для операций обмена с удалёнными репозиториями.

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

• git-протокол (схема URI — git:) — открытый протокол [15] , требующий наличия на сервере запущенного git-демона [16] (поставляется вместе с Git), протокол не имеет средств аутентификации пользователей;
• SSH (ssh:) — использует аутентификацию пользователей с помощью пар ключей, а также встроенный в Unix-систему «основной» SSH-сервер (sshd), со стороны сервера требуется создание учётных записей с git в качестве оболочки;
• HTTP и HTTPS (http:, https:) — использует инструмент curl (для Windows — поставляется вместе с git), и его возможности HTTP-аутентификации, как и его поддержку SSL и сертификатов.

В последнем случае требуется работа на серверной стороне веб-приложения, исполняющего роль прослойки между командами Git на сервере и HTTP-сервером (среди таковых WebGitNet, разработанный на ASP.NET MVC 4). Кроме поддержки серверной стороны команд push и pull, такие веб-приложения могут также давать доступ только на чтение к репозиторию через веб-браузер.

Графические интерфейсы [ править | править код ]

Разработано множество графических интерфейсов для системы, среди них — GitKraken (кроссплатформенный бесплатный клиент Git), SmartGit (кроссплатформенный интерфейс на Java), gitk (простая и быстрая программа, написана на Tcl/Tk, распространяемая с самим Git), Giggle (вариант на Gtk+), TortoiseGit (интерфейс, реализованный как расширение для проводника Windows), SourceTree (бесплатный Git-клиент для Windows и Mac), Github-клиент и ряд других.

Кроме того, разработано множество веб-фронтендов, в числе которых GitWebAdmin, GitLab, Gitblit, Gerrit, Gitweb, Kallithea, Gitea.

Git-хостинг [ править | править код ]

Ряд сервисов предоставляют хостинг для git-репозиториев, среди наиболее известных — GitHub, Codebase, SourceForge, Gitorious, Bitbucket, GitLab.

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

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

Основы основ работы с GIT

GIT — это определённый набор утилит командной строки, отслеживающих и записывающих изменения в файлах. При помощи его, возможно, восстанавливать предыдущие версии ваших программ, сравнивать, анализировать, совмещать изменения и многое другое. Такой процесс принято называть контроль версий. На сегодняшний день есть много систем контроля версий, выполняющих такую же работу. Вы могли уже слышать ранее о некоторых из них – SVN, Mercurial, Perforce, CVS, Bitkeeper.

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

1. Установка GIT

Установить GIT на ваш компьютер несложно:

• Linux – просто откройте терминал и установите GIT через менеджер пакетов вашего дистрибутива. Команда для Ubuntu: sudo apt-get install git ;
• Windows – можно воспользоваться установщиком на официально сайте или более лучший вариант GIT для Windows , так как он включает и графический клиент (GUI client), и эмулятор командной строки BASH;
• OS X – легче всего воспользоваться homebrew и ввести команду brew install git в вашем терминале.

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

2. Первоначальная настройка GIT

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

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

3. Создание нового репозитория – git init

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

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

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

Это означает, что репозиторий успешно создан, но всё ещё пуст. А теперь создайте простой текстовый файл hello.txt и сохраните в папку git_exersice.

4. Проверка статуса – git status

GIT статус это ещё одна необходимая для изучения команда, которая возвращает информацию о текущем состоянии репозитория: всё ли сохранилось, что сохранилось нового, что поменялось и так далее. На команду git status в нашем новом репозитории должен прийти такой ответ:

Полученное сообщение показывает, что файл hello.txt не отслеживается. Это означает, что файл новый, и GIT ещё не знает, должен ли отслеживать вносимые в него изменения или же игнорировать. Для подтверждения файла следует его добавить в индекс.

5. Индексирование – git add

У GIT есть понятие «области индексирования». Его можно представить себе, как пустой холст для хранения изменений, которые вы хотели бы зафиксировать. Изначально область появляется пустой, но вы можете добавлять к ней файлы (или даже отдельные строки и части файлов) с помощью команды git add и, наконец, всё сохранить (создать своеобразный «скриншот») с помощью git commit .

В нашем случае у нас есть только один файл, поэтому его и добавим:

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

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

Файл готов для сохранения (создания коммита)! Это сообщение о статусе также говорит нам, что было изменено в отношении файлов в области индексирования, в данном случае о появлении нового файла (new file), но файл может показываться как modified или deleted, в зависимости от действий с ним с момента прошлой команды git add .

6. Сохранение изменений – git commit

Зафиксированные изменения показывают состояние репозитория в определённый момент времени. Как скриншот, с помощью которого мы просматриваем состояние вещей в прошлом.

Для создания новой сохранённой версии файлов нам нужно добавить как минимум одно изменение в область индексирования (мы только что это сделали с git add ) и ввести следующую команду:

Эта команда создаст новый «скриншот» со всеми сделанными изменениями (включая hello.txt). Часть -m "Initial commmit" – это краткий комментарий, написанный пользователем, к данной версии файлов. Хорошая привычка – регулярно фиксировать и всегда писать внятный комментарий.

Удалённые репозитории и GIT

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

1. Подключение к удалённому репозиторию – git remote add

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

Для соединения нашего локального репозитория с удалённым на GitHub, мы должны в терминале вести следующую строку:

Один проект может иметь несколько удалённых репозиториев одновременно. Для их разделения нужно дать им разные имена. Традиционно основной удалённый GIT-репозиторий называют origin.

2. Загрузка на сервер – git push

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

Команда GIT для push, git push , имеет два параметра – имя удалённого репозитория (мы назвали наш origin) и ветка для отправки (ветка по умолчанию для каждого удалённого репозитория – master).

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

3. Клонирование репозитория – git clone

После клонирования другие люди смогут увидеть и изучить ваш удалённый репозиторий на GitHub. Также будет возможно загрузить его локально и иметь полную рабочую копию вашего проекта с командой git clone :

Новый локальный репозиторий создаётся автоматически, с GitHub-версией, настроенной как удалённый репозиторий.

4. Получение изменений с сервера – git pull

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

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

Ветви в GIT

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

• Исправная, стабильная версия кода не будет повреждена;
• Люди могут безопасно разрабатывать собственные версии отдельно друг от друга;
• Разработчики могут работать на своей ветви без опасения, что кто-то изменит их код;
• Когда разработчики не уверены, как сделать лучше, они могут работать над своими версиями в отдельных ветвях, а затем сравнить результаты между собой.

1. Создание новых ветвей – git branch

Ветвь по умолчанию для каждого репозитория называется master. Для создания другой используйте команду git branch .

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с master.

2. Смена ветвей – git checkout

Теперь, когда мы выполнили команду git branch , мы получили доступ к двум опциям:

Master – текущая ветвь и помечена звёздочкой. Однако мы хотим работать над новыми замечательными версиями программы, поэтому нам нужно переключиться на другую ветвь. Это делается командой git checkout с указанием одного параметра – ветвь для переключения.

3. Объединение ветвей – git merge

Наша «новая версия» будет просто другим текстовым файлом под названием feature.txt. Мы создадим его, добавим и зафиксируем.

Далее мы вернемся в ветвь master.

Теперь, если мы откроем наш проект в файловом менеджере, мы заметим, что feature.txt исчез. Это потому, что мы вернулись в master-ветвь, и здесь feature.txt так и не был создан. Чтобы перенести его сюда, нам нужно объединить две ветви вместе командой git merge , применив изменения, сделанные в amazing_new_feature, к основной версии проекта.

Ветвь master обновлена, а ветвь awesome_new_feature branch больше не нужна и мы можем её удалить.

Продвинутый уровень GIT, ещё больше полезных команд

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

1. Просмотр отличий между сохранёнными версиями

Каждая зафиксированная версия программы имеет уникальный идентификационный номер в формате строки из чисел и символов. Для просмотра списка коммитов (сохранённых версий) с их идефикаторами мы можем использовать команду git log :

Как видите, >git show [commit] :

Просмотреть отличия двух любых коммитов можно с помощью команды git diff с указанием на требуемые версии: [commit-from]..[commit-to].

Мы сравнили первый коммит с последним и увидели все изменения, когда-либо внесённые. Обычно это проще сделать, используя команду git difftool , которая покажет все различия между началом и концом в графическом клиенте.

2. Возвращение файла в предыдущую версию

GIT позволяет нам вернуть любой выбранный файл назад в одно из сохранённых его состояний. Это делается через команду git checkout , которую мы уже использовали для смены ветвей, но она также может переключать версии (достаточно часто в GIT одна команда используется для нескольких кажущихся совершенно не связанных между собой действий).

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

3. Исправление коммита

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

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

Ей может быть присвоено имя HEAD.

В подобных случаях лучше всего использовать id-номер.

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

4. Разрешение конфликтов объединения

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

Давайте посмотрим на пример, где мы будем пытаться объединить две ветви, называющиеся john_branch и tim_branch. И Джон, и Тим записывают в одном и том же файле функцию, которая отображает все элементы в массиве.

Джон использует цикл for:

Тим же предпочёл forEach:

Они оба фиксируют свой код на собственных ветвях. Теперь, если они попытаются объединить эти две ветви, то увидят следующее сообщение об ошибке:

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

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

Как только всё будет отлажено, должна появиться объединённая фиксация.

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

5. Настройка .gitignore

Во многих проектах присутствуют файлы или папки, которые мы не хотим фиксировать. Мы можем «железно» заблокировать их включение в наш git add –A созданием файла .gitignore:

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

Хорошие примеры игнорируемых файлов:

• лог-файлы;
• сборщик задач;
• папка node_modules в проектах node.js;
• папки, созданные такими IDE (интегрированные среды разработки), как Netbeans и IntelliJ;
• личные примечания разработчика.

Файл .gitignore блокирует всё вышеуказанное примерно подобным образом:

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

Заключение

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

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

• Официальная документация GIT, включая полную книгу и видеоуроки ;
• Получение прав GIT– коллекция уроков и статей Atlassian ;
• Список графических клиентов ;
• Памятка о GIT (PDF) ;
• Создать .gitignore файл онлайн .

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