Каждый действующий или начинающий разработчик, член команды или фрилансер, работающий на дому, должен использовать систему контроля версий для своего кода. Это позволяет вам делать ошибки и экспериментировать, не беспокоясь о том, чтобы вернуться к приложению, которое когда-то работало. Работа на нескольких машинах была утомительна, а совместная работа с другими была почти невозможна до тех пор, пока бородатые компьютерные гении не придумали такие вещи, как Git, мою любимую программу управления исходным кодом.
Эта статья посвящена Git и использованию git из командной строки. Есть несколько полнофункциональных графических интерфейсов для git, но большинство разработчиков считают, что командная строка в сочетании с просмотрщиком графического интерфейса более эффективна. Я знаю, у Линуса нет бороды, но он должен…
Основной рабочий процесс
Если вы еще не установили git на свой компьютер, прочтите статью «Установка Git».
Начав с основ, мы создадим «репозиторий», внесем некоторые изменения и «зафиксируем» эти изменения в репозитории. Суть в том, чтобы иметь историю вашего кода, к которой вы всегда можете вернуться. Сначала откройте терминал, создайте каталог и перейдите в него:
cd ~/Desktop
mkdir my_app
cd my_app
Шаг 1 : Создайте репозиторий:
$ git init
Initialized empty Git repository in ~/Desktop/my_app/.git/
Git создал репозиторий в формате .git. Если бы вы открыли скрытый каталог, вы бы увидели что-то вроде этого:
my_app/
.git/
config
description
HEAD
hooks/
info/
objects/
refs/
В отличие от SVN, это единственное место, где вы найдете какие-либо папки git, он не создает .svnв каждом отдельном подкаталоге (ура!). Прямо сейчас с этим каталогом нечего делать, просто знайте, что он там. Если вам все неудобно, просто удалите, .gitи все вещи git исчезнут. Также полезно знать, что если вы развертываете старый-школьный-непросвещенный-ftp-стиль, вы можете опустить .gitкаталог при загрузке.
Шаг 2 : Делайте вещи. Создайте файл README с помощью текстового редактора и сохраните файл в папке my_app, или выполните команду командной строки следующим образом:
echo "I am a git repo." > README
Чтобы увидеть, что происходит, запустите statusкоманду. Он покажет вам, какие файлы не отслеживаются, были изменены, удалены и т. д.
git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# README
Шаг 3 : «Постановка» ваших изменений.
$ git add README
Постановка ваших изменений иногда кажется ненужным шагом новичкам и новообращенным svn. По сути, мы просто сообщаем git, что хотим, чтобы README был включен в следующий «коммит». Вы можете передать имя файла или любой путь, я обычно просто делаю
git add.
и все. Вы также должны добавить измененные файлы, которые уже существуют, если вы хотите, чтобы они были в следующем коммите.
Шаг 4 : Зафиксируйте изменения
git commit -m 'This is my first commit evar'
[master (root-commit) 206e419] This is my first commit evar
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
Все, что было «подготовлено» или добавлено, фиксируется в вашем репозитории. «Коммит» — это что-то вроде моментального снимка вашего кода. Почти так же, как вы создаете zip-файл и сохраняете его где-нибудь (за исключением более эффективного способа). Он всегда будет там; вы можете обращаться к нему, когда захотите.
Теперь моем, полощем, повторяем: вносим изменения, добавляем, фиксируем.
git add.
git commit -m 'whatever message you want'
Если вы только изменили файлы и не создали новых, вы можете использовать этот ярлык и пропустить git addшаг, но помните, что это захватит только те файлы, которые уже были добавлены ранее :
git commit -a -m 'whatever message you want'
Шаг 5. Отмените некоторые изменения.
Внесите некоторые изменения READMEв свой репозиторий, затем выполните эту команду:
git checkout README
Вернувшись в текстовый редактор, файл должен вернуться к тому состоянию, в котором он был в последний раз, когда вы делали коммит.
Эти четыре простые команды, init, add, commitи checkoutпозволят вам создать историю вашего кода и устранить всевозможные риски в процессе разработки.
Удаленные репозитории (на github)
Работа с удаленным репозиторием — отличный способ работать с нескольких компьютеров, сотрудничать с другими разработчиками и создавать резервные копии исходного кода. Удаленный репозиторий — это просто еще один репозиторий, обычно на другом сервере, в который вы можете передавать свои коммиты и получать из них другие коммиты.
Если у вас еще нет учетной записи на github, создайте ее, потому что мы будем использовать ее в следующих примерах.
Шаг 1 : Создайте репозиторий на github. Войдите в систему и нажмите «Новый репозиторий». Назовите его my_app, если хотите.
Шаг 2 : Добавьте удаленный репозиторий в локальное «рабочее дерево». Откройте терминал и вернитесь к my_app(возможно, он все еще открыт?). Мы собираемся добавить «удаленный».
git remote add origin git@github.com:your_name/my_app.git
Синтаксис такой git remote add <name> <url>. Мы назвали это удаленное «источник» не по соглашению. Вы можете иметь несколько пультов и давать им разные имена, например «сцена» или «производство». Проверьте все свои пульты с помощью git remoteили git remote -v.
Шаг 3 : Отправьте свои коммиты в удаленный репозиторий.
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 242 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To /example/my_app.git
* [new branch] master -> master
Синтаксис git push <remote> <branch>. Мы еще не говорили о ветках, но по умолчанию используется master. Вы можете видеть, что он упаковывает все, а затем отправляет в удаленный репозиторий. Если у вас было несколько коммитов, он подталкивает их все вверх. Я призываю всех наших разработчиков чаще совершать и нажимать.
Шаг 4 : Извлеките изменения из исходного репозитория. Хорошей практикой является получение перед отправкой, чтобы убедиться, что у вас есть самый последний код. На самом деле, я тяну просто так в течение дня.
git pull origin master
Тот же синтаксис, что и у push, git pull <remote> <branch>. Это извлекает любые коммиты, которые есть на удаленном компьютере, которых нет в вашем локальном рабочем дереве, и автоматически объединяет их. Обычно слияние происходит без каких-либо проблем, но иногда у вас будут конфликты, которые обычно легко исправить.
Расширенный рабочий процесс
Я не решаюсь назвать это «продвинутым», так как git такой мощный, но для новичка это продвинутый: P
Как правило, вы не хотите работать над «главной» веткой — вместо этого вы создаете тематические ветки кода, работаете, а затем снова объединяете ветки. Git является гибким, поэтому вы можете создать любую модель ветвления/рабочего процесса, которую вы хотите, я представлю здесь очень простую (да, базовую, расширенную, рабочий процесс).
При разработке новых функций вы не можете избежать исправления ошибок в текущей версии. Давайте рассмотрим сценарий, в котором мы начинаем разработку новой функции и одновременно исправляем ошибки в текущем выпуске.
Вот снимок моего приложения прямо сейчас.
Проверьте новую ветку функции : сначала проверьте новую ветку, в которой будет разрабатываться функция. После того, как это будет создано, внесите некоторые изменения и зафиксируйте их.
git checkout -b develop-awesome-feature
Внесите некоторые изменения
Теперь зафиксируйте.
git commit -a -m 'started the add_stuff method'
Ой! Нам не хватает заключительной цитаты в строке 8. Это приложение находится в разработке, поэтому нам нужно быстро это исправить, мы не можем дождаться завершения add_stuff.
Проверьте ветку исправления ошибок : нам нужна новая ветка исправления ошибок для работы. Прежде чем мы это сделаем, убедитесь, что вы знаете, на какой ветке вы находитесь:
git branch
* develop-awesome-feature
master
Эта звездочка сообщает вам, где вы сейчас работаете. Поскольку наше исправление ошибок имеет высокий приоритет и, вероятно, будет завершено до появления новой функции, мы сначала переключаемся обратно на основную ветку, а затем от нее отходим. Обратите внимание, что в прошлый раз, когда мы это делали git checkout -b, это синтаксис для создания новых ветвей, после создания вы просто используете git checkout.
git checkout master
Посмотрите на файл сейчас:
Весь код нашей новой функции исчез, а это именно то, что нам нужно. Теперь мы можем исправить ошибку в отдельной ветке и обновить приложение без кучи неиспользуемого — и потенциально сломанного — кода разработки из нашей фичи; и нам не нужно ждать add_stuffзавершения, прежде чем мы сможем выпустить исправление. Освобождение? Да. Хорошо, вернемся к работе. Проверьте новую ветку на наличие ошибки, добавьте цитату в строку 8 и зафиксируйте:
git checkout -b develop-bug-quotes
Switched to a new branch 'develop-bug-quotes'
Теперь добавьте цитату к строке 8 и зафиксируйте.
git commit -a -m 'fixed quote bug'
[develop-bug-quotes 89d6037] fixed quote bug
1 files changed, 1 insertions(+), 1 deletions(-)
Объедините исправление ошибки с мастером : поскольку мы работаем над нашей веткой исправления ошибок, в основной ветке еще нет исправления. Нам нужно объединить ветку исправления ошибок с веткой master. Подобное слияние — это торт, но сначала вы должны обратить внимание на то, какую ветку вы проверили. При слиянии git объединит ветку с веткой, в которой вы работаете, поэтому давайте сначала извлечем master.
git checkout master
Switched to branch 'master'
git merge develop-bug-quotes
Updating 48d01de..89d6037
Fast-forward
application | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Теперь вы можете развернуть это приложение, не дожидаясь завершения новой функции. Довольно гладко. Прежде чем мы двинемся дальше, вам действительно не нужно, чтобы эта ветка висела вечно. Давайте удалим его — не нервничайте, git будет жаловаться, если ваши изменения еще не слиты, и не удалит ветку. (Вы обнаружите, что почти невозможно что-либо потерять при использовании git.)
git branch -d develop-bug-quotes
Объедините исправление ошибки с веткой функций : это та часть, которую вы так долго ждали. Переключитесь обратно на develop-awesome-featureветку и посмотрите на код, у нас снова ошибка! Сливаемся еще раз.
git checkout develop-awesome-feature
git merge master
Auto-merging application
CONFLICT (content): Merge conflict in application
Automatic merge failed; fix conflicts and then commit the result.
Ну вот. Конфликт. Обычно мои слияния не вызывают конфликтов, особенно когда я работаю один, но это не значит, что я не сталкиваюсь с конфликтами почти ежедневно. Есть несколько отличных инструментов слияния, которые помогут вам в этом. Я работаю на Mac и мне очень нравится использовать встроенное приложение FileMerge для разрешения конфликтов. Я покажу, как это использовать, но сначала давайте посмотрим, как это сделать в любом старом текстовом редакторе. Git добавил кое-что в файл, взгляните:
В строке 5 показано, что находится в текущей «HEAD» (в основном, в вашей проверенной ветке), а затем после ====== показано, что находится в master, или что git пытался объединить. Просто избавьтесь от всего мусора и убедитесь, что все выглядит так, как вы хотите:
Сохраните файл и зафиксируйте.
git commit -a -m 'merged with branch master'
Давайте посмотрим, как использовать mergetoolв следующий раз, когда у вас возникнет конфликт.
git mergetool
merge tool candidates: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse ecmerge p4merge araxis emerge vimdiff
Merging the files: application
Normal merge conflict for 'application':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (opendiff):
Я нажимаю Enter, и появляется FileMerge, и я разбираюсь с конфликтами:
Все это время git терпеливо ждет сохранения файла. Когда я сохраняю файл (File »Save) и выхожу из приложения, git улавливает это. Он также оставляет в репозитории файл с именем application.original. Если вы довольны результатом слияния, удалите этот новый файл. Если нет, он будет там как ссылка, пока вы разбираетесь (но в конечном итоге вам нужно его удалить). Когда вы довольны слиянием, зафиксируйте изменения:
git commit -a -m 'merged with branch master'
Завершить нашу функцию : теперь, когда мы объединили исправление с нашей функциональной веткой, мы можем закончить то, что начали так давно.
И затем, конечно, совершить:
git commit -a -m 'finished add_stuff feature'
Затем мы объединяем его с мастером, чтобы мы могли его развернуть:
git checkout master
Switched to branch 'master'
git merge develop-awesome-feature
Updating d959c84..3ec8885
Fast-forward
application | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
Теперь мы можем удалить и эту ветку, так как она нам больше не нужна:
git branch -d develop-awesome-feature
Инструменты с графическим интерфейсом : Git поставляется с чем-то, что называется gitk, в OS X многие люди вместо этого используют GitX (я в этой лодке), а в Windows — TortoiseGit. Вот скриншот того, что мы делали в течение этого рабочего процесса в GitX:
gitx
Git ОГРОМНЫЙ. Кажется, каждую неделю я узнаю что-то новое, что можно сделать с помощью git. Но, как видите, даже поверхностное знакомство с его возможностями сделает вашу разработку гораздо более гибкой, чем она была бы в противном случае. Ознакомьтесь с ресурсами git, чтобы узнать о других замечательных местах.