Здійснюємо патчі (patches), Азбука W€B
Секрет твого успіху
Main topic описано: Git
Оригінал: http://drupal.org/node/1134754 Переклад: http://azbukaweb.ru/practicing-patches
Тепер Ви можете писати прості модулі Drupal із тестами. Вітаємо! Однак, у реальній роботі це рідко буває потрібно для написання власних модулів для Drupal у перших проектах. У більшості випадків існує вже готовий модуль, який робить те, що Вам потрібне чи щось близьке. Якщо Ви розробляєте новий функціонал для існуючого модуля або виправляєте проблему, Ви захочете зробити так, щоб ваше коригування стало доступним спільноті Drupal.
Git доступ
Спільнота, що розвиває Drupal, використовує Git для управління всіма версіями кожного файлу, з яких складається система Drupal. Якщо Ви не знайомі з Git, то можете прочитати це в документації, доступній на drupal.org, починаючи з Introduction to Git. Вам знадобиться доступ до Git із Вашого комп'ютера. Про це дивіться тут: Installing Git.
Для використання Git на drupal.org Ви повинні мати обліковий запис на сайті та прийняти угоду про доступ до Git 'Git access agreement', розташовану на вкладці 'Edit' Вашого облікового запису у вкладці 'Git access.' Детальні інструкції дивіться в Obtaining Git access, потім, для завершення установки, перегляньте Identifying yourself to Git.
Клонування сховища (repository)
Тепер спершу зробимо патч. Спочатку відвідайте пісочницю Current content. Дотримуючись посилання вгорі, перейдіть на 'Version control', Потім запускайте свій термінал і вводьте команди для клонування сховища. (У цьому навчальному курсі будуть інструкції для доступу з командного рядка. Якщо Ви використовуєте GUI (Графічний інтерфейс), Вам потрібно будеконвертувати ці команди.) Якщо Ви клонуєте код всередині вашої папки http://example.com/sites/all/modules , Ви можете перевірити функціональність і виконати тест.
Створюємо патч (patch)
За допомогою Git Ви часто можете виявити кілька патчів, що трохи відрізняються, для однієї і тієї ж ділянки коду. Для патчів це нормально. Якщо у Вас вже є власний процес і Ви хочете лише потренуватися, не соромтеся, працюючи над ним. Тут ми використовуємо відгалуження від нашого основного модуля, тому ми можемо як створювати, так і рецензувати патчі, не торкаючись клонованого оригіналу. Якщо у Вас є проблеми з будь-якими з цих інструкцій, перегляньте посилання внизу.
checkout повідомляє системі, що Ви змінюєте гілки. -b означає, що цією командою Ви створюєте нову гілку з ім'ям, що йде за ним. Ви можете назвати нову гілку, як вам подобається, але найкраще дотримуватися рекомендації використовувати номер звернення, щоб бути впевненими, що Ви не переплутаєте її з іншими зверненнями. Ми включили в ім'я гілки слово 'patch', щоб відрізняти її від іншої, яку Ви робитимете для перевірки.
Коли ви будете задоволені змінами, їх можна буде викласти. Поверніться в термінал (or Git GUI) і введіть команду:
Команда status повинна показати, що Ви все ще на гілці з 'patch' на ім'я. Вона повинна повідомити Вам, що файл .module був змінений, але не збережений. Наступна команда:
Ця команда є остаточною перевіркою Ваших змін. Переконайтеся, що сюди включено все, що ви бажали. Якщо Ви випадково увімкнули порожній простір, Git висвітить його для Вас. Переконайтеся, що Ви видалили цей простір. Намагайтеся зробити все правильно, перш ніж переходити до наступного кроку. Потрібно включити всі ваші зміни доодне вивантаження.
Коли все буде готове, вивантажуйте Ваші зміни. Прапор -A означає залучення у розвантаження інформації про всі нові, змінені та віддалені файли:
Якщо Ви виконаєте зараз git status , побачите список Ваших файлів у 'Changes to be committed'. Тепер відправка:
Повідомлення надсилання відповідає директивам drupal.org. За повними поясненнями звертайтесь на Commit messages – providing history and credit. Далі, отримуємо останній код, якщо є якісь зміни:
Git видасть Вам повідомлення про те, що він доставив та розпакував об'єкти з 'Current content' назад на drupal.org. Тепер застосовуємо останні зміни, які Вам щойно доставлені:
Ви отримаєте повідомлення про те, що Git переніс у HEAD та застосував Ваші зміни. Тепер ви готові створити файл патчу (patch).
Створення patch файлу
Існує два способи розгорнути патч:
Переконайтеся, що не використовуєте символ # в імені файлу, інакше робот, що тестує, не пропустить патч. (Насправді тут може і не бути автоматичної перевірки, але вона буде обов'язково, якщо Ви робите патч для ядра системи.)
Кілька передач. Якщо Ви робите більше однієї передачі, то можете використовувати git diff :
Як тільки ви повторите цю команду Git зробить патч без екранних повідомлень. Ви можете знайти файл в корені каталогу вашого поточного локального сховища Git. (Цей процес працює тільки до одного каталогу, і якщо Ваш паттч все ж таки лежить у його підкаталозі, збережений він буде все одно в корені.) Відкрийте його і перевірте свою роботу. Якщо Ви використовували git format-patch, то патч буде починатися з чотирьох рядків, які включають хеш передачі, ім'я та email того, хто робив патч, дату та повідомлення передачі. Якщо вивикористовували git diff, то патч може починатися по-різному. Якщо Ви робили зміни для посилання Далі ("More"), Ваш патч буде включати секції, кожна з яких починається з номера рядка та імені функції, для якої зроблено зміни.
Тепер повернемося до черги звернень для 'Current content', вивантажимо Ваш патч і позначимо звернення як 'Needs review.'
Якщо Ви виконаєте git status для гілки, то побачите там патч файл. Для того, щоб Ви випадково не включили цей патч у майбутні відправки, видаліть його за допомогою Unix команди rm:
Перегляд патчу
Тепер поверніться до вашого терміналу та каталогу current_content. Перевірте статус:
Якщо Ви не в гілці master, то перейдіть туди:
Далі, переконайтеся в тому, що ви все ще використовуєте останню версію коду:
Створіть гілку для рецензування патчу:
Існує кілька способів для завантаження та застосування патча. Якщо Ви хочете використовувати curl, дивіться Advanced patch contributor guide у розділі 'Reviewing patches'. ми ж будемо використовувати Unix команду wget:
Скопіюйте та вставте URL-адресу патча, щоб не допустити помилку в команді завантаження. Під час завантаження патча Ви отримаєте купу даних. Якщо використовувати прапорець -v, то буде видано повідомлення про те, чи залежить цей патч від інших.
Якщо тепер виконати git status , Ви побачите, що файл патча включений. Для того, щоб Ви випадково не включили цей патч у майбутні відправки, видаліть його за допомогою Unix команди rm:
Перегляд змін у коді:
Тепер перевіримо патч. Оскільки пісочниці не включають функції автоматичної перевірки, виконаємо тести SimpleTest на своєму сайті. Зауважте, що ви намагаєтеся зробити, що працює, не працює і напишіть про це у своєму зверненні (issue). Для отримання більшДетальнішу інформацію про те, як рецензувати патчі, дивіться Reviewing patches.
Висновок
Ура! Ви пройшли весь навчальний курс до кінця. Якщо ви пройшли з нами з самого початку, то тепер Ви знайомі з хуками, блоками, меню, базою даних, формами, масивами представлення (render arrays), функціями сторінок, деякими функціями drupal, SimpleTest та патчами за допомогою Git.
Що далі? Подивіться, що зацікавить Вас у Working with the Drupal API та у Examples for Developers.