.git — sublime не видит скрытую папку .git


Содержание

Git не видит новые файлы, только папка

При добавлении папки с несколькими новыми файлами в мой проект и выполнении git-статуса git сообщает мне только о папке, а не о файлах. Когда я добавил -A, была добавлена только папка и никакие файлы, и когда я нажимаю и вытаскиваю, происходит только папка, а не файлы.

Что я делаю не так?

Скажем, у вас есть следующая неподготовленная папка:

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

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

Поскольку git только отслеживает файлы, а не папки, поведение в отношении push и pull невозможно. Невозможно добавить пустой каталог в git.
Однако для git status это ожидаемое поведение, так как все файлы в папке являются новыми, потому что git еще не отслеживает файл внутри этой папки.

Кроме того, проверьте школу git, вызов 7. Если вы git status там git status , вы увидите этот вывод, хотя octofamily содержит два файла:

Это просто упрощение в пользовательском интерфейсе, вы все еще можете сделать git add octofamily/baby_octocat.txt (Однако, не в школе git, потому что это не настоящий git-клиент).

Следующий git status теперь будет отражать это:

Обратите внимание, что теперь он показывает файлы внутри octofamily , потому что теперь эта папка известна.

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

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

2) Если сохранить историю git содержимого папок не важно, удаление папки .git внутри приведет к возврату нормального поведения git.

3) Если вы хотите сохранить историю, вы можете вместо этого использовать git subtree для копирования ветки в новое репо. Это делает файлы доступными для редактирования локально, и история по-прежнему доступна.

Следующая команда скопирует содержимое и историю другой локальной ветки репо в текущую локальную ветвь.

git subtree add —prefix=[newFolderName] [/path/to/other/repo] HEAD

(Замените квадратные скобки с указанием названия и пути по вашему выбору)

Работаем с Git, основные команды для начинающих

Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:

Превратим наш проект в репозиторий git. Для начала просто создайте папку git_site , затем введите следующие команды:

Где mkdir — команда для создания новых каталогов;
cd — переход в указанную папку; команда cd используется для смены текущего каталога.
cd .. на уровень выше
cd \ в корень текущего диска
d: перейти на диск D
cd c:\windows перейти в каталог windows

После инициализации каталога будет выведено соответствующее сообщение:

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

$ git add

Далее в наш каталог ( git_site ) можно поместить файлы сайта. Скопируем файлы сайта в папку git_site . Далее, давайте добавим файлы в репозиторий.

Для этого понадобится выполнить команду:

$ git status

Команда $ git status позволяет отследить состояние репозитория. Эта команда позволяет узнать, какие изменения необходимо зарегистрировать git (при необходимости, отменить).

$ git commit –a , $ git commit –am «. «, $ git commit –a –m «. «

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

–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.

Подтверждение с описанием выполненных действий.

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

$ git stash

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

$ git stash list

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

На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.

$ git stash pop

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

$ git merge

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

Давайте удалим ветку hotfix . Для этого воспользуемся следующей командой:

Ветвление

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

$ git checkout –b

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

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

Теперь давайте внесем изменения в файл index.html . Например, давайте подключим стилевой файл. И в самом стилевом файле увеличим размер шрифта у параграфа. Сделаем git status и зарегистрируем изменения:

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

git init (инициализируем git реп-й)

Чтобы проинициализировать Git репозиторий введите команду:

Будет создана папка /.git/ . Репозиторий — это скрытая папка, в которой работает Git.


git status (Проверяем статус)

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

git add (добавляем файл)

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

Сейчас git отслеживает наш файл test.txt. Давайте выполним

снова, чтобы понять, что изменилось!

git commit (фиксируем изменения)

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

git commit -m «Add cute octocat story»

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору. В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора (для этого в редакторе по-умолчанию (Vim) вам нужно нажать клавишу ESC , ввести :wq и нажать Enter ). Вы увидите . (http://githowto.com/ru/commiting_changes)

Используем маску

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

git commit –a –m ”new comment here”

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

Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,

—amend

git commit —amend

Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,

Второй коммит заменит результат первого и в итоге останется 1 коммит

Работаем с GitHub

Зарегистрируйтесь на GitHub. Создайте репозиторий.

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

Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git

Выполняем команду с указанными аргументами:

git remote add origin https://github.com/try-git/try_git.git

Где origin — имя удаленного репозитория.

Плюсы и минусы bitbucket.org и GitHub

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Процесс разработки:

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

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

Ключ –v показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

Коммитим и пушим на GitHub (global настройки matching и simple)

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

То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

В данном случае протолкнется лишь текущая ветка.

git remote (прсматриваем уд. реп.)

Команда git remote позволяет просмотреть удаленные репозитории

git remote -v параметр -v позволяет увидеть URL-адреса.

git remote add (добавляем уд. реп.)

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

git remote add [сокращенное имя] [url]

git remote add kuku [url] — теперь вместо полного URL-адреса в командную строку можно вводить имя kuku

В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master

Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku

git remote show (получаем инфо. об уд. реп.)

Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.

git fetch (извлечение данных из уд. реп.)

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

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

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

git push (проталкиваем изменения)


Команда git push говорит Git, куда отправить наши изменения, когда все готово. Итак, запушим наши локальные изменения в наш удаленный репозиторий на GitHub. Имя удаленного репозитория origin , а ветка по умолчанию называется master (не думайте пока что о ветках). Параметр -u позволит нам в будущем не указывать дополнительные параметры, а просто выполнять git push . Git будет знать, что нужно делать.

git push -u origin master

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

git pull (стягиваем изменения)

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

Цукерберг рекомендует:  Искуственный интеллект - Последствия прогресса

git pull origin master

Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.

git diff, git diff HEAD

Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда git dif —cached покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

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

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

git reset (Откатываем изменения/удаляем файлы из промежуточной области)

Вы можете удалять файлы из промежуточной области с помощью git reset .

git reset octofamily/octodog.txt

git log (информация о последних коммитах)

Иногда просто хочется вернуться назад и забыть все изменения до определенного момента, потому что все они были неправильными. В таком случае Для просмотра изменений (истории коммитов) используется команда

покажет список последних коммитов и их хеши SHA1.

На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:

Например, мы можем выводить историю в более удобном формате:

%h – короткий код самого коммита;
%an – автор;
%ar – когда был сделан;
%s — комментарий.

Ограничиваем коммиты по времени:

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

—stat используется для получения краткой статистики по каждому коммиту.

—graph добавляет графику с историей ветвлений и слияний

git checkout (Отмена изменений)

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

git checkout — octocat.txt

git checkout 82f5

Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.

git checkout (получаем уд. ветку)

Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :

(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.

git branch (создаем ветку)

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

Давайте создадим новую ветку и назовем ее clean_up :

git branch clean_up

git branch -d (удаление ветки)

Вы можете использовать команда git branch -d
для удаления ветки. Сделаем это:

git branch -d clean_up

git branch -vv (наблюдаем за уд. ветками)

Команда git branch -vv позволяет получить список всех веток, за которыми идет наблюдение (за какой веткой следит на уд. сервере и на сколько опережает соотв. ветку на уд. сервере).

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

git rm (удаляем файлы)

Команды git rm , которая не только удалит файлы с диска, но и добавит сведения об их удалении в Git.

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

merge (смержим в текущую ветку другую)

Настал момент, когда вы должны смержить изменения из ветки clean_up в ветку master .

Мы уже находимся в ветке master (вы уже знаете, как в этом убедиться). Осталось только сказать Git, что мы хотим смержить в текущую ветку другую — clean_up :

git merge clean_up

git clone

По url создаем локальный репозиторий, склонировав удаленный, например, с gitHub. Предварительно необходимо выполнить команду git init .


$ mkdir epicgame & cd epicgame
$ git init
$ git remote add
$ git clone

rejected

Если при push появляется rejected , то это говорит о том, что необходимо скачать изменения с удаленного сервере и уже затем push -ть.

Конфликты

Сообщение о конфликте:

В статусе ( git st ) появляется блок:

То есть у нас появились файлы, которые автоматически не с merg -сь.

То есть в самом файле:

Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).

Разные полезные команды:

Добавляем пользователя:

(config – работаем с конфигом; —global – ключ для глобального конфига; user.name — имя).

(задаем email глобально)

(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )

Игнорирование файлов:

На одном уровне с папкой .git создаем текстовый документ: .gitignore (убираем разрешение .txt, то есть сохраняем с All types(.) в Notepad++).

В самом файле указываем игнорирование, например:

$ git rm

Файл name_file.txt станет обратно ( untracked ; от track — следить), то есть вернется в состояние перед командой git add .

СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ

Без ключа –m откроется редактор vim ( :x – означает сохранить и выйти).

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

Изменения можно проверить в C:\Users\name_user\.gitconfig

ВЕТКИ ($ git checkout –b new_branch)

Создаем ветку new_f и тут же переходим в нее.

С использованием –v показывает ветки с последними коммитами.

merge

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

Указываем какой утилитой будем разрешать конфликты

Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):

Как заставить Sublime Text 2 показывать папки и файлы git на боковой панели?

при добавлении папки в проект Sublime Text 2 она не отображается .git подпапках. Также кажется, что эти файлы не могут быть открыты Ctrl-P .

Я отключил плагин Git, но это не помогло.

2 ответов

в Sublime Text, перейдите в Настройки — > Настройки-по умолчанию, прокрутите вниз до строки 290 и удалить .git из свойства ‘folder_exclude_patterns’

на Preferences -> Settings-User . Измените правило folder_exclude_patterns содержит массив из модели исключить. Я решил оставить его пустым:

Шпаргалка по консольным командам Git

Nihil doloremque possimus dolorem est aut ut dolorum. Sunt laboriosam molestiae explicabo esse enim voluptatem voluptatem. Magni voluptatem distinctio in sit qui sit consequatur et. Sint dolorem inventore et ut commodi consequatur.

Vel omnis dolores aut nam labore quia velit. Est enim ut nisi quasi assumenda.

Autem omnis est voluptatem vero. Voluptatibus voluptatibus magni porro. Maxime ratione adipisci et. Commodi sint expedita dolores architecto molestiae et facere. Autem illo autem distinctio aut totam repudiandae. Et omnis voluptates quia consequatur dolores dolor. Neque ab non amet et quis.

Sint quisquam nihil quia eveniet. Ad sunt similique voluptatem est ea. Unde quae eos fuga.

Eveniet ut quod sequi dolorum neque. Quas natus omnis fugiat qui ipsam blanditiis. Iste itaque possimus quidem et ea. Eum non aliquid quia adipisci. Hic occaecati molestiae reiciendis suscipit quisquam consequatur odio. Illo illum qui quibusdam a. Veritatis accusamus consectetur impedit animi alias ut. Laudantium nobis est excepturi illum. Libero aliquid qui eos odio magnam et dolor in.

Общее

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

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

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Концепция GIT

Ключ к пониманию концепции git — знание о «трех деревьях»:

  • Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
  • Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
  • Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

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

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

Простейший цикл работ


  • Редактирование, добавление, удаление файлов (собственно, работа).
  • Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
  • Коммит (фиксация изменений).
  • Возврат к шагу 1 или отход ко сну.

Указатели

  • HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
  • ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
  • Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
  • Теги — простые указатели на коммиты. Не перемещаются.

Настройки

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

Если вы в Windows:

Указание неотслеживаемых файлов

Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.

Консоль

Длинный вывод в консоли: Vim

Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .

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 :

Цукерберг рекомендует:  Как с помощью CSS спозиционировать один объект относительно другого

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

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

Команда 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 :

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
его имя (кстати, в моей старой версии 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-сервер


wpupru / Gists for SublimeText3

Настройка GitHub Gist в sublime text 3
Первым делом нам нужно сгенерировать token.
Переходим на свой гитхаб, идем в settings и там в пункте Applications жмем Generate new token
Далее называем его как угодно и выбираем только один пункт gist и жмем генерировать.
Теперь устанавливаем полученный token в preferences => Package Settings => Gits => Settings-Default
Вторым пунктом, настраиваем комбинацию клавиш
Переходим preferences => Package Settings => Gits => Key Bindings-user
И изменяем как нам удобно, вот мой пример
[
< "keys": ["ctrl+k+i"], "command": "gist" >,
< "keys": ["ctrl+k", "ctrl+p"], "command": "gist_private" >,
< "keys": ["ctrl+k", "ctrl+s"], "command": "gist_update_file" >,
< "keys": ["ctrl+k+o"], "command": "gist_list" >,
< "keys": ["ctrl+k", "ctrl+["], "command": "insert_gist_list" >,
]
Установка и настройка завершена.
Если комбинации клавиш настроенна аналогичны настроенным, то для создания gist’а нужно просто выделить подходящий код и нажать ctrl+k+i,
затем указать подходящее название, что выполняет код и выбрать название файла.
Чтобы использовать сохраненный ранее gist нужно нажать ctrl+k+o и выбрать код.

This comment has been minimized.

Copy link Quote reply

ergokonuni commented May 13, 2020

Thank you a lot, Friend!

This comment has been minimized.

Copy link Quote reply

AlexeyKuzmich commented Dec 1, 2020

This comment has been minimized.

Copy link Quote reply

NoN >Jan 26, 2020

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

This comment has been minimized.

Copy link Quote reply

sakerdon commented Jan 28, 2020

Тоже не мог вставить.
Посмотрел по пути C:\Users\admin\AppData\Roaming\Sublime Text 3\Packages\Gist\Gist.sublime-settings нет такой папки и файла \Gist\Gist.sublime-settings Создал их ручками, скопировал настройки туда, вставил токен и всё заработало.

P.S. папка AppData — скрытая.

This comment has been minimized.

Copy link Quote reply

Leon >Jul 22, 2020 •

Вы не можете вставить так как редактор по не известной мне причине не создал папку Gist в каталоге C:\Users\user_name\AppData\Roaming\Sublime Text 3\Packages (если не видите папку AppDate надо включить видимость папок google в помощь).
Решение:

  1. Скачать плагин;
  2. Распаковать по указанному выше пути;
  3. Переименовать в «Gist» (удалить -master)

This comment has been minimized.

Copy link Quote reply

ghost commented Apr 13, 2020

Cracking guide for Sublime Text 3.2.1 (3207) and Sublime Merge (1111)

Updated #12 (20200412)

The patch will show the license key for Sublime Text/Merge!

One license key for Sublime Text/Merge!

User URL
cipherhater Cracking guide for Sublime Text/Merge

Read the guide, run the script, enjoy . :)

Cracking guide for VueScan 9 x64 (v9.6.38)

User URL
cipherhater Cracking guide for VueScan 9.6.38

Read the guide, run the script, enjoy . :)

«We do not pay for programs that you do not know how to protect. » © CipherHater

Основные команды консоли Git Bash

Шпаргалка по основным командам для работы с файловой системой в консоли Git Bash.

Установка консоли Git Bash

Мы будем использовать консоль Git Bash.
Чтобы ее использовать, необходимо установить Git и Git Bash
Установим с сайта: https://git-scm.com.

Команды в Git Bash консоли

clear — Очистить консоль

pwd — Показать текущий каталог
ls — Показать файлы в данной папке, кроме скрытых
ls -f — Показать файлы в данной папке, включая и скрытые
cd c:/ — Перейти в конкретный каталог
cd — — Вернуться назад
cd .. — Выйти на 1 уровень вверх
cd ../.. — Выйти на 2 уровня вверх

Создание каталогов

mkdir — Создать папку
cd !$ — Перейти в только что созданную папку
mkdir -p — Создать сразу несколько папок
mkdir -p app/ — Создать сразу несколько вложенных папок

Создание файлов

touch index.html — Создать файл index.html
touch app/ — Создать сразу несколько файлов, никаких лишних пробелов быть не должно

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

touch — позволяет создавать файлы
rm test — Удалить пустую папку test
rm -r test — Удалить папку test с файлами внутри неё

Перемещение файлов

mv app1/*.* app2 — Переместить все файлы из папки app1 в папку app2


Git GUI в Windows не видит папку .git из общего ресурса Samba

СЦЕНАРИЙ
Я использую Vagrant, среду Windows и запускаю Ubuntu внутри виртуальной коробки для своей работы по разработке. Я настроил экземпляр сервера Samba, и я запускаю доступ к виртуальной машине через vagrant и Git Bash и запускаю команду
net use A: \\192.168.91.11\www vagrant /persistent:no /user:vagrant
в windows cmd. Это создает виртуальный диск в Windows, и я могу получить доступ ко всем файлам Linux из Windows. Операции, связанные с Git, работают нормально с Bash CLI. Я хочу попробовать и настроить Git GUI, такой как TortoiseGit.

ЭТА ПРОБЛЕМА
Я не могу увидеть папку .git внутри виртуального диска. Я уже пытался изменить параметры папки, чтобы показать скрытые папки, показать архивы, удалить только чтение с диска, но папка .git все еще остается скрытой. Папка .git видна, когда я запускаю команду ll на CLI. Однако он остается скрытым, когда я получаю доступ к виртуальному диску из Windows. Интересно, есть ли способ использовать графический интерфейс в этой настройке? Извините за длинное описание, но мне нужен совет здесь. Если есть какой-либо другой способ реализовать GUI в этой настройке, я все уши! Благодарю.

РЕДАКТИРОВАТЬ
Поэтому я клонировал свой репозиторий и при просмотре списка я вижу папку .git как показано на снимке экрана выше.

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

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

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

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

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

Установка Git

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

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

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

Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init , которая создает директорию .git со всей информацией о вашем проекте.

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

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

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

Готовим файлы для коммита

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

Проверяем состояние репозитария

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

Добавляем файлы в Git

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

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

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

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

Удаляем файлы

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

Коммитим изменения

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

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

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

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

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.

Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff . Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff .

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

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

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

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

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

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

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

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://www.sitepoint.com/git-for-beginners/
Перевел: Станислав Протасевич
Урок создан: 23 Мая 2014
Просмотров: 55656
Правила перепечатки

5 последних уроков рубрики «Разное»

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

Разработка веб-сайтов с помощью онлайн платформы Wrike

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

20 ресурсов для прототипирования

Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

Быстрая заметка: массовый UPDATE в MySQL

Ни для кого не секрет как в MySQL реализовать массовый INSERT, а вот с UPDATE-ом могут возникнуть сложности. Чтобы не прибегать к манипуляциям события ON_DUPLICATE можно воспользоваться специальной конструкцией CASE … WHEN … THEN.

Prgm / Scripts

Начинаем работать с Git — первые шаги

Для чего нужен GIT

Git — система управления контроля версиями, репозитории Git содержат файлы, историю, конфигурации управляемые Git. Данные могут отправляться из локальной папки в Git репозиторий и обратно, локальное состояние подразумевает рабочую папку которая содержит измененные файлы готовые для помещения в .git каталог, при помещении в данный каталог — Commit, указываются комментарии к данному коммиту, что по факту является историей, удаленный репозиторий содержит ветки Branches, основная ветка называется Master, данные могут отправляться как в Master, так и другие ветки (ответвления) проекта.

Команды GIT

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

  • История команд
  • По командам можно найти обширную информацию в интернете
  • Командная строка представляет более полный контроль
  • Команды одинаково работают в любых ОС / дистрибутивах

В Linux (CentOS / Fedora) устновка Git достаточно проста:

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