Полезное
Мы Вконтакте
Discord канал
Если вы графический или web дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и спровоцировал проблему, кто поставил задачу и когда, и многое другое. Использование VCS также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо накладок. Вы можете использовать контроль версий практически для любых типов файлов. Многие люди в качестве метода контроля версий применяют копирование файлов в отдельную директорию (возможно даже директорию с отметкой по времени, если они достаточно умны). Данный подход очень распространён из-за его простоты, однако он, невероятным образом, подвержен появлению ошибок. Можно легко забыть в какой директории вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.
Первое, что вам следует сделать после установки Git’а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git’е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config —global user.email johndoe@example.com
Если указана опция —global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе.
Если указана опция —global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе.
Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git’е. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Мне удобнее использовать Notepad++ установить его по умолчанию можно так:
Естественно, что notepad++ должен быть установлен именно по этому пути: C:/Program Files (x86)/Notepad++/notepad++.exe
Если вы собираетесь начать использовать Git для существующего проекта, то вам необходимо перейти в директорию проекта и в командной строке ввести:
Эта команда создаёт в текущей директории новую поддиректорию с именем .git, содержащую все необходимые файлы репозитория — основу Git-репозитория. На этом этапе ваш проект ещё не находится под версионным контролем.
Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первый коммит изменений. Добиться этого вы сможете запустив команду git add несколько раз, указав индексируемые файлы, а затем выполнив git commit:
Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.
Для получения копии существующего Git-репозитория, например, проекта, в который вы хотите внести свой вклад, необходимо использовать команду git clone. Для того, чтобы клонировать репозиторий в директорию с именем, необходимо указать желаемое имя, как параметр командной строки:
В Git’е реализовано несколько транспортных протоколов, которые вы можете использовать. В предыдущем примере использовался протокол https://, вы также можете встретить git:// или user@server:path/to/repo.git, использующий протокол передачи SSH.
Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Предположим, вы добавили в свой проект новый файл, простой файл README. Если этого файла раньше не было, и вы выполните git status, вы увидите свой неотслеживаемый файл вот так:
# On branch master
# Untracked files:
# (use «git add
#
# README
nothing added to commit but untracked files present (use «git add» to track)
Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status. Статус «неотслеживаемый файл», по сути, означает, что Git видит файл, отсутствующий в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите.
Чтобы начать отслеживать изменение в файлах используйте команду git add.
Для файла readme, чтобы начать отслеживать все файлы в папке используйте
Если вы снова выполните команду status, то увидите, что файл README теперь отслеживаемый и индексированный:
Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы. В таком случае, вы можете создать файл .gitignore с перечислением шаблонов соответствующих таким файлам. Откройте GitBush и перейдите в папку с проектом, введите touch .gitignore это создаст gitignore.
Вот пример файла .gitignore:
Первая строка предписывает Git’у игнорировать любые файлы заканчивающиеся на .o или .a — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (~).
Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.
Если результат работы команды git status недостаточно информативен для вас — вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff. Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
+ run_code(x, ‘commits 1′) do
+ git.commits.size
+ end
+
run_code(x, ‘commits 2′) do
log = git.commits(‘master’, 15)
log.size
Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff —cached. (В Git’е версии 1.6.1 и выше, вы также можете использовать git diff —staged). Эта команда сравнивает ваши индексированные изменения с последним коммитом.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status, вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit:
Эта команда откроет выбранный вами текстовый редактор. Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы («выхлоп») команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit, указав его после параметра -m, как в следующем примере:
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита (463dc4f), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и торчит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add:
Обратите внимание на то, что в данном случае перед коммитом вам не нужно выполнять git add для файла benchmarks.rb.
Для того чтобы удалить файл из Git’а, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm, которая также удаляет файл из вашего рабочего каталога, так что вы в следующий раз не увидите его как “не отслеживаемый”.
После следующего коммита файл исчезнет и больше не будет отслеживаться. Если вы изменили файл и уже проиндексировали его, вы должны использовать принудительное удаление с помощью параметра -f.
После того, как вы создали несколько коммитов или же склонировали репозиторий с уже существующей историей коммитов, вероятно вам понадобится возможность посмотреть что было сделано – историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда git log. Если вы запустите команду git log в папке склонированного проекта, вы увидите следующий вывод:
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700
removed unnecessary test
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700
first commit
По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке – последние коммиты находятся вверху. Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям. Посмотрим на наиболее популярные из них. Одним из наиболее полезных аргументов является -p, который показывает разницу, внесенную в каждый коммит. Так же вы можете использовать аргумент -2, который позволяет установить лимит на вывод количества коммитов.
Если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию —stat:
Это команда работает с большим количеством форматов – вы можете указать определенную дату вида «2008-01-15″ или же относительную дату, например «2 years 1 day 3 minutes ago».
В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git’а, где неверными действиями можно необратимо удалить результаты своей работы.
Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит, можно запустить commit с параметром —amend (дополнить):
Отмена индексирования файла:
Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md? Как можно просто «разызменить» его ? вернуть к тому виду, который был в последнем коммите (или к изначально склонированому, или еще как-то полученному в рабочий каталог)?
Важно понимать, что git checkout — [file] — опасная команда. Любые изменения соответствующего файла пропадают — вы просто копируете поверх него другой файл. Ни в коем случае не используйте эту команду, если вы не убеждены, что файл вам не нужен.
Удаленные репозитории это версии вашего проекта, которые размещаются в интернете или где-то в сети. Чтобы добавить новый репозиторий используйте команду git remote add [shortname] [url]:
Чтобы получить список всех удаленных репозиториев существует команда git remote
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)
Чтобы получить данные из удаленных проектов, вы можете запустить:
Команда тянет из удаленной ветки все данные, которые у вас еще нет. Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch).
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Выполнение git pull, как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: git push [удал. сервер] [ветка]. Чтобы отправить вашу ветку master на сервер origin. Вы можете выполнить следующую команду для отправки наработок на сервер:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push.
Для переименования ссылок в новых версиях Git’а можно вылолнить git remote rename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul, вы можете сделать это следующим образом:
Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm:
В качестве средства для совместной разработки я использую «Ведро битов». В отличии от Github, он позволяет создавать неограниченное количество репозиториев как открытых, так и приватных. Бесплатно над проектом может работать до пяти человек. Первое что нужно сделать это создать rsa ключ для доступа к репозиторию (https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git)
Git оболочка уже поставляется с клиентом SSH. Откройте Git Bash и выполните следующие действия, чтобы проверить установку:
$ ssh -v
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
…
Проверьте содержимое ~/.ssh папки
Если у вас уже есть идентификатор по умолчанию, вы увидите два id_ * файла:
В этом случае вы уже можете использовать RSA идентификатор по умолчанию (id_rsa.pub) в вашей учетной записи BitBucket. Можете пропустить следующую секцию.
По умолчанию, система добавляет ключи для всех идентичностей в каталог /Users/yourname/.ssh. Следующая процедура создает идентичности по умолчанию.
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Documents and Settings/manthony/.ssh/id_rsa):
Команда создана два файла, один для открытого ключа (id_rsa.pub) и один для закрытого ключа ( id_rsa).
Host bitbucket.org
IdentityFile ~/.ssh/id_rsa
Сохраните и закройте файл.
[master (root-commit) 15ee0ca] Initial commit with contributors
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 TestDoc.txt
Отличная работа, теперь вы все настроено! Да, чтобы не вводить постоянно пароль push/pull запросах можно снова воспользоваться командой:
На вопрос для ключевой фразы, оставьте это поле пустым и просто нажмите клавишу ВВОД. Так же можно при создании ключей опустить ключевую фразу. (Если на Windows 8 столкнётесь с проблемами, попробуйте так сделать)
Пример использования Git вместе с Unreal Engine
*.sdf
*.suo
Binaries/
Build/
Intermediate/
Saved/
Выполните git init
git add –A
Теперь добавим пользователя, чтобы можно было работать совместно. Для этого нажмите настройки в репозитории, выберите управление доступом затем введите имя пользователя на Bitbucket, как только вы это сделаете ему придёт письмо с приглашением которое он должен принять.
git commit –m “add readme file”
git push origin master
Теперь readme есть и у вас.
Гитом пользоваться просто, а польза от него неоценима. Я описал лишь базовые понятие позволяющие «Встать и идти» для более глубокого понимания советую официальную рускоязычную книгу Pro Git. Для работы будет достаточно первых 200 страниц.
https://git-scm.com/book/en/v2
Так же стоит упомянуть что существуют графические оболочки для Git и Bitbucket – Git GUI и Source Tree.
Учебные материалы
Учим ветвления
За статью спасибо: Вадиму Невскому, Jquest’у (форматирование)
Вы должны войти, что бы оставлять комментарии.