git-commit - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

git-commit - Запис змін до сховища

СИНТАКСИС

мерзотник commit [-a | --інтерактивний | --patch] [-s] [-v] [-u ] [--виправити]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -м ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--дата= ] [--cleanup= ] [--[без статусу]
[-i | -o] [-S[ ]] [--] [ ...]

ОПИС

Зберігає поточний вміст індексу в новому коміті разом із повідомленням журналу від
користувач, який описує зміни.

Вміст, який потрібно додати, можна вказати кількома способами:

1. за допомогою мерзотник додавати щоб поступово «додавати» зміни до індексу перед використанням commit
команда (Примітка: навіть змінені файли потрібно «додати»);

2. за допомогою мерзотник rm щоб видалити файли з робочого дерева та індексу, знову ж таки
використання commit командування;

3. шляхом перерахування файлів як аргументів для commit команда, у цьому випадку коміт буде
ігнорувати зміни, внесені в покажчик, і натомість записувати поточний вміст
перераховані файли (які вже повинні бути відомі Git);

4. за допомогою перемикача -a з commit команду, щоб автоматично «додавати» зміни з усіх
відомі файли (тобто всі файли, які вже перераховані в індексі) та автоматично
"rm" файли в індексі, які були видалені з робочого дерева, а потім виконати
фактичне вчинення;

5. за допомогою перемикачів --interactive або --patch із commit команда вирішити одне
за допомогою того, які файли або шматки мають бути частиною коміту, перед завершенням
операція. Дивіться розділ «Інтерактивний режим». git-додати(1) навчитися працювати
ці режими.

Параметр --dry-run можна використовувати, щоб отримати підсумок того, що включено до будь-якої з них
вище для наступного коміту, вказавши той самий набір параметрів (параметрів і шляхів).

Якщо ви зробите фіксацію, а потім відразу знайдете помилку, ви зможете відновитися
це з мерзотник скидання.

ВАРІАНТИ

-а, --усі
Повідомте команді, щоб вона автоматично розставляла файли, які були змінені та видалені, але
нові файли, про які ви не повідомили Git, це не впливає.

-p, --патч
Використовуйте інтерактивний інтерфейс вибору патчів, щоб вибрати зміни, які потрібно зафіксувати. Побачити
git-додати(1) для деталей.

-C , --reuse-message=
Візьміть існуючий об’єкт фіксації та повторно використовуйте повідомлення журналу та авторство
інформацію (включаючи позначку часу) під час створення коміту.

-c , --reedit-message=
Люблю -C, але з -c викликається редактор, щоб користувач міг далі редагувати файл
повідомлення про фіксацію.

--виправлення=
Створіть повідомлення про фіксацію для використання з rebase --autosquash. Повідомлення про фіксацію буде
бути рядком теми із зазначеного коміту з префіксом "fixup!". Побачити git-
ребаза(1) для деталей.

--squash=
Створіть повідомлення про фіксацію для використання з rebase --autosquash. Повідомлення про фіксацію
Тема береться із зазначеного коміту з префіксом "squash!". Може бути
використовується з додатковими параметрами повідомлення про фіксацію (-m/-c/-C/-F). Побачити git-rebase(1) для
подробиці

--reset-author
При використанні з параметрами -C/-c/--amend або при фіксації після конфлікту
cherry-pick, заявляємо, що авторство отриманого коміту тепер належить
комітер. Це також оновлює позначку часу автора.

--короткі
Виконуючи сухий тест, дайте результат у короткому форматі. Побачити git-статус(1) для
деталі. Має на увазі --сухий хід.

-філія
Показувати філію та інформацію про відстеження навіть у короткому форматі.

--порцеляна
Виконуючи сухий тест, дайте результат у форматі, готовому до порцеляни. Побачити git-статус(1)
для деталей. Має на увазі --сухий хід.

--довго
Виконуючи сухий запуск, надайте результат у довгому форматі. Має на увазі --сухий хід.

-z, --нуль
При відображенні короткого або порцелянового виводу стану завершіть записи у виводі стану
з NUL, замість LF. Якщо формат не вказано, означає вихідний формат --porcelain.

-Ф , --file=
Візьміть повідомлення про фіксацію з даного файлу. Використовуйте - щоб прочитати повідомлення від
стандартний вхід.

--автор=
Замінити автора фіксації. Укажіть явного автора, використовуючи стандартний AU Thor
<[захищено електронною поштою]> формат. Інакше вважається шаблоном і використовується
для пошуку наявного коміта цього автора (тобто rev-list --all -i
--автор= ); потім автор коміту копіюється з першого знайденого такого коміту.

--дата=
Замінити дату автора, використану в коміті.

-м , --message=
Використовуйте дане як повідомлення про фіксацію. Якщо дано кілька варіантів -m, їх
значення об’єднуються як окремі параграфи.

-т , --template=
Під час редагування повідомлення про фіксацію запустіть редактор із вмістом зазначеного файлу.
Для надання цієї опції часто використовується змінна конфігурації commit.template
неявно до команди. Цей механізм можуть використовувати проекти, які хочуть керувати
учасники з деякими підказками, що писати в повідомленні в якому порядку. Якщо
користувач виходить з редактора, не редагуючи повідомлення, фіксація переривається. Це не має
ефект, коли повідомлення надається іншим способом, наприклад, за допомогою параметрів -m або -F.

-s, --signoff
Додайте рядок Signed-off-by комітером в кінці повідомлення журналу фіксації. The
значення signoff залежить від проекту, але зазвичай він засвідчує цього комітера
має право подавати цей твір за такою ж ліцензією та погоджується розробнику
Сертифікат походження (див http://developercertificate.org/ для отримання додаткової інформації).

-n, --не перевіряти
Цей параметр обходить гачки pre-commit і commit-msg. Дивись також гітхуки(5).

--дозволити-порожній
Зазвичай запис коміту, який має те саме дерево, що й єдиний батьківський коміт, є a
помилка, і команда не дає вам зробити такий комміт. Цей параметр обходить стороною
безпеки, і в першу чергу призначений для використання іноземними сценаріями інтерфейсу SCM.

--allow-empty-message
Як і --allow-empty, ця команда в основному призначена для використання іноземними сценаріями інтерфейсу SCM.
Це дозволяє створювати коміти з порожнім повідомленням коміту без використання сантехніки
команди, як git-дерево-комітів(1).

--очищення=
Цей параметр визначає, як перед цим має бути очищено надане повідомлення про фіксацію
вчинення. The може бути смугою, пробілом, дослівним текстом, ножицями або за умовчанням.

роздягнутися
Зніміть провідні та кінцеві порожні рядки, кінцеві пробіли, коментарі та
згортати послідовні порожні рядки.

пробіл
Те саме, що і смуга, за винятком того, що #коментар не видаляється.

дослівно
Не змінюйте повідомлення взагалі.

ножиці
Те саме, що і пробіли, за винятком того, що все з (і включно) рядка "#
------------------------ >8 ------------------------ " скорочується, якщо повідомлення
має бути відредагований. "#" можна налаштувати за допомогою core.commentChar.

дефолт
Те саме, що і полоска, якщо повідомлення потрібно відредагувати. Інакше пробіли.

Значення за замовчуванням можна змінити за допомогою commit.cleanup змінна конфігурації (див git-
конфиг(1)).

-е, --едіт
Повідомлення береться з файлу за допомогою -F, командного рядка за допомогою -m і з об'єкта фіксації за допомогою
-C зазвичай використовуються як незмінене повідомлення журналу фіксації. Ця опція дозволяє далі
редагувати повідомлення, взяті з цих джерел.

--не редагувати
Використовуйте вибране повідомлення про фіксацію, не запускаючи редактор. Наприклад, git commit
--amend --no-edit вносить зміни до коміту, не змінюючи його повідомлення про фіксацію.

--виправити
Замініть наконечник поточної гілки, створивши новий коміт. Записане дерево є
підготовлено як зазвичай (включаючи ефект параметрів -i та -o та явно
pathspec), а повідомлення з вихідного коміту використовується як відправна точка,
замість порожнього повідомлення, якщо в командному рядку не вказано інше повідомлення
за допомогою таких параметрів, як -m, -F, -c тощо. Новий коміт має тих самих батьків та автора, що й
поточний (опція --reset-author може протидіяти цьому).

Це приблизний еквівалент для:

$ git reset --soft HEAD^
$ ... зробіть щось інше, щоб придумати потрібне дерево ...
$ git commit -c ORIG_HEAD

але може використовуватися для внесення змін до коміту злиття.

Ви повинні розуміти наслідки переписування історії, якщо ви змінюєте фіксацію
вже опубліковано. (Дивіться розділ «ВІДНОВЛЕННЯ ВІД ВЕРХНЕЇ БАЗА» в git-
ребаза(1)).

--без перезапису
Обійти хук після перезапису.

-i, --включати
Перш ніж робити комміт із поетапного вмісту, поставте вміст шляхів
також наведено в командному рядку. Зазвичай це не те, чого ви хочете, якщо ви цього не хочете
завершення конфліктного злиття.

-о, --тільки
Зробіть фіксацію, взявши оновлений вміст робочого дерева зазначених шляхів
командному рядку, не враховуючи вміст, який було створено для інших шляхів.
Це режим роботи за замовчуванням мерзотник commit якщо якісь шляхи вказані на
командний рядок, у цьому випадку цю опцію можна пропустити. Якщо вказана ця опція
Разом з --виправити, тоді не потрібно вказувати шляхи, які можна використовувати для внесення змін
останній комміт без фіксації змін, які вже були виконані.

-у[ ], --untracked-files[= ]
Показати невідстежувані файли.

Параметр режиму є необов'язковим (за замовчуванням всі), і використовується для визначення обробки
невідстежуваних файлів; коли -u не використовується, за замовчуванням нормальний, тобто показувати без відстеження
файли та каталоги.

Можливі варіанти:

· немає - Не показувати файли, які не відстежуються

· нормальний - Показує невідстежувані файли та каталоги

· всі - Також показує окремі файли в невідстежуваних каталогах.

Значення за замовчуванням можна змінити за допомогою конфігурації status.showUntrackedFiles
змінна, задокументована в git-config(1).

-v, -- багатослівний
Показати уніфіковану відмінність між фіксацією HEAD і тим, що буде фіксовано в нижній частині
шаблон повідомлення про фіксацію, щоб допомогти користувачеві описати комміт, нагадуючи, що
зміни в коміті. Зауважте, що цей вихідний розбіжність не має префікса рядків
з #. Цей diff не буде частиною повідомлення про фіксацію.

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

-q, -- тихо
Придушити підсумкове повідомлення про фіксацію.

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

--статус
Включити вихід git-статус(1) у шаблоні повідомлення про фіксацію під час використання an
редактор для підготовки повідомлення про фіксацію. За замовчуванням увімкнено, але можна використовувати для заміни
змінна конфігурації commit.status.

--без статусу
Не включати вихід git-статус(1) у шаблоні повідомлення про фіксацію під час використання
редактор для підготовки повідомлення про фіксацію за замовчуванням.

-S[ ], --gpg-sign[= ]
GPG-знак фіксує. Аргумент keyid є необов'язковим і за замовчуванням для комітера
ідентичність; якщо вказано, він повинен бути закріплений за параметром без пробілу.

--no-gpg-sign
Countermand змінна конфігурації commit.gpgSign, яка налаштована на примусове використання кожної
зобов’язуються підписати.

--
Більше не інтерпретуйте аргументи як варіанти.

...
Коли файли вводяться в командний рядок, команда фіксує вміст файлу
іменовані файли без запису вже внесених змін. Вміст цих файлів
також інсценуються для наступного коміту на додаток до того, що було поставлено раніше.

ДАТА ПРОВЕДЕННЯ ФОРМАТИ

Змінні середовища GIT_AUTHOR_DATE, GIT_COMMITTER_DATE і параметр --date
підтримують такі формати дати:

Внутрішній формат Git
це є , де є числом
секунд з часів епохи UNIX. є позитивним або негативним зміщенням
від UTC. Наприклад, CET (що на 2 години попереду за UTC) дорівнює +0200.

RFC 2822
Стандартний формат електронної пошти, описаний у RFC 2822, наприклад, чт, 07 квітня 2005 р.
22:13:13 +0200.

ISO 8601
Час і дата визначені стандартом ISO 8601, наприклад 2005-04-07T22:13:13. The
аналізатор також приймає пробіл замість символу T.

примітки
Крім того, частина дати приймається в таких форматах: РРРР.ММ.ДД,
ММ/ДД/РРРР та ДД.ММ.РРРР.

ПРИКЛАДИ

Під час запису власної роботи вміст змінених файлів у вашому робочому дереві відображається
тимчасово зберігається в проміжній області, яка називається "індексом" с мерзотник додавати. Файл може бути
повернувся назад, тільки в індексі, але не в робочому дереві, до останнього коміту
з git reset HEAD -- , який ефективно повертається мерзотник додавати і запобігає змінам
до цього файлу від участі в наступному коміті. Після побудови держави бути
фіксується поступово за допомогою цих команд, git commit (без будь-якого параметра імені шляху)
використовується для запису того, що було поставлено до цього часу. Це найпростіша форма команди.
Приклад:

$ редагувати hello.c
$ git rm до побачення.c
$ git додати hello.c
$ git фіксація

Замість того, щоб створювати файли після кожної окремої зміни, ви можете вказати git commit помічати
зміни до файлів, вміст яких відстежується у вашому робочому дереві, і зробити
відповідні git add і git rm для вас. Тобто цей приклад робить те саме, що і
попередній приклад, якщо у вашому робочому дереві немає інших змін:

$ редагувати hello.c
$ rm до побачення.c
$ git фіксація -a

Команда git commit -a спочатку дивиться на ваше робоче дерево, помічає, що ви внесли зміни
hello.c і видалений goodbye.c, і виконує необхідні git add і git rm для вас.

Після внесення змін до багатьох файлів ви можете змінити порядок запису змін,
шляхом надання шляхів до git commit. Коли вказано імена шляхів, команда виконує фіксацію
який записує лише зміни, внесені до названих шляхів:

$ редагувати hello.c hello.h
$ git додати hello.c hello.h
$ редагувати Makefile
$ git фіксує Makefile

Це створює фіксацію, яка записує зміни до Makefile. Зміни, проведені для
hello.c і hello.h не входять до отриманого коміту. Проте їх зміни є
не втрачені — вони все ще інсценуються і просто стримуються. Після зазначеної вище послідовності, якщо ви
робити:

$ git фіксація

цей другий коміт запише зміни до hello.c і hello.h, як і очікувалося.

Після злиття (ініційованого мерзотник злиття or мерзотник тягнути) зупиняється через конфлікти, чисто
об’єднані шляхи вже поетапно зафіксовані для вас, а шляхи, які конфліктують, є
залишено в незлитому стані. Вам потрібно спочатку перевірити, з якими шляхами конфліктують мерзотник
статус і, закріпивши їх вручну в робочому дереві, ви поставте результат як
звичайний с мерзотник додавати:

$ git status | grep роз’єднано
не об’єднано: hello.c
$ редагувати hello.c
$ git додати hello.c

Після вирішення конфліктів і встановлення результату git ls-files -u перестане згадувати
конфліктний шлях. Коли ви закінчите, запустіть git commit, щоб остаточно записати злиття:

$ git фіксація

Як і у випадку для запису власних змін, ви можете використовувати опцію -a, щоб зберегти введення. один
Різниця полягає в тому, що під час вирішення злиття ви не можете використовувати git commit з іменами шляхів до
змінити порядок фіксації змін, оскільки злиття має бути записано як a
єдина фіксація. Фактично, команда відмовляється виконуватися, коли надаються імена шляху (але див. -i
варіант).

ОБГОВОРЕННЯ

Хоча це не обов’язково, бажано починати повідомлення про фіксацію з одного короткого
(менше 50 символів) рядок, що підсумовує зміну, за яким слідує порожній рядок, а потім a
більш детальний опис. Текст до першого порожнього рядка в повідомленні фіксації є
розглядається як заголовок фіксації, і ця назва використовується в усьому Git. Наприклад, git-
формат-патч(1) перетворює фіксацію на електронну пошту та використовує заголовок у рядку Тема та
решта фіксації в тілі.

Git певною мірою не залежить від кодування символів.

· Вміст об'єктів BLOB - це неінтерпретовані послідовності байтів. Немає
кодування перекладу на базовому рівні.

· Назви шляхів кодуються у формі нормалізації UTF-8 C. Це стосується об'єктів дерева,
файл індексу, імена посилань, а також імена шляхів у аргументах командного рядка,
змінні середовища та файли конфігурації (.git/config (див git-config(1)), гітигнорувати(5)
gitattributes(5) і gitmodules(5)).

Зверніть увагу, що Git на базовому рівні розглядає імена шляхів просто як послідовності, які не мають значення NUL
байтів, немає перетворення кодування імен шляху (за винятком Mac і Windows).
Таким чином, використання імен шляхів, відмінних від ASCII, здебільшого працюватиме навіть на платформах і файлах
системи, які використовують застарілі розширені кодування ASCII. Однак репозиторії, створені на
такі системи не працюватимуть належним чином у системах на основі UTF-8 (наприклад, Linux, Mac, Windows)
і навпаки. Крім того, багато інструментів на основі Git просто приймають імена шляхів
UTF-8 і не зможе правильно відобразити інші кодування.

· Повідомлення журналу фіксації зазвичай кодуються в UTF-8, але інші розширені кодування ASCII
також підтримуються. Сюди входять ISO-8859-x, CP125x та багато інших, але НЕ
Багатобайтові кодування UTF-16/32, EBCDIC і CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
і т.д.).

Хоча ми рекомендуємо, щоб повідомлення журналу фіксації були закодовані в UTF-8, як ядро, так і
Git Porcelain розроблений так, щоб не нав’язувати UTF-8 у проектах. Якщо всі учасники а
конкретному проекту зручніше використовувати застарілі кодування, Git не забороняє
це. Однак варто пам’ятати про декілька речей.

1. мерзотник commit та мерзотник дерево комітів видає попередження, якщо надане йому повідомлення журналу фіксації
не виглядає як дійсний рядок UTF-8, якщо ви явно не вкажете, що ваш проект використовує a
застаріле кодування. Щоб сказати це, потрібно мати i18n.commitencoding у .git/config
файл, наприклад:

[i18n]
кодування комітів = ISO-8859-1

Об’єкти фіксації, створені з наведеним вище параметром, записують значення i18n.commitencoding
у його заголовку кодування. Це допоможе іншим людям, які пізніше подивляться на них. Відсутність
цей заголовок означає, що повідомлення журналу фіксації закодовано в UTF-8.

2. мерзотник журнал, мерзотник Показувати, мерзотник звинувачувати і друзі дивляться на заголовок кодування коміту
об’єкта та спробуйте перекодувати повідомлення журналу в UTF-8, якщо не вказано інше. ти
може вказати потрібне кодування вихідних даних за допомогою i18n.logoutputencoding у .git/config
файл, наприклад:

[i18n]
кодування вихідних даних = ISO-8859-1

Якщо у вас немає цієї змінної конфігурації, значення i18n.commitencoding таке
використовується замість цього.

Зауважте, що ми свідомо вирішили не перекодувати повідомлення журналу фіксації, коли є фіксація
зроблено для примусового використання UTF-8 на рівні об’єкта фіксації, оскільки перекодування на UTF-8 не є
обов'язково оборотна операція.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ І КОНФІГУРАЦІЯ ЗМІННІ

Редактор, який використовується для редагування повідомлення журналу фіксації, буде вибрано з GIT_EDITOR
змінна середовища, змінна конфігурації core.editor, середовище VISUAL
змінну, або змінну середовища EDITOR (у такому порядку). Побачити git-вар(1) для деталей.

ГУКИ

Ця команда може запускати гачки commit-msg, ready-commit-msg, pre-commit та post-commit.
Читати гітхуки(5) для отримання додаткової інформації.

Використовуйте git-commit онлайн за допомогою служб onworks.net