git-commit — Online w chmurze

PROGRAM:

IMIĘ

git-commit - Zapisuje zmiany w repozytorium

STRESZCZENIE

odrzutowiec popełnić [-a | --interaktywny | --patch] [-s] [-v] [-u ] [--poprawiać]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -M ] [--reset-autor] [--zezwalaj na puste]
[--zezwól na pustą wiadomość] [--no-verify] [-e] [--author= ]
[--data= ] [--czyszczenie= ] [--[brak statusu]
[-i | -o] [-S[ ]] [--] [ ...]

OPIS

Przechowuje bieżącą zawartość indeksu w nowym zatwierdzeniu wraz z komunikatem dziennika z pliku
użytkownik opisujący zmiany.

Treść do dodania można określić na kilka sposobów:

1. za pomocą odrzutowiec Dodaj aby stopniowo „dodawać” zmiany do indeksu przed użyciem popełnić
polecenie (Uwaga: nawet zmodyfikowane pliki muszą zostać „dodane”);

2. za pomocą odrzutowiec rm aby usunąć pliki z drzewa roboczego i indeksu, ponownie wcześniej
używając popełnić Komenda;

3. wymieniając pliki jako argumenty do popełnić polecenie, w którym to przypadku zatwierdzenie będzie
zignoruj ​​zmiany wprowadzone w indeksie i zamiast tego zapisz bieżącą zawartość pliku
wymienione pliki (które muszą być już znane Git);

4. używając przełącznika -a z opcją popełnić polecenie automatycznego „dodania” zmian ze wszystkich
znane pliki (tj. wszystkie pliki, które są już wymienione w indeksie) i automatycznie
„rm” pliki w indeksie, które zostały usunięte z drzewa roboczego, a następnie wykonać
faktyczne zatwierdzenie;

5. używając przełączników --interactive lub --patch z opcją popełnić polecenie, aby zdecydować jeden
przez jeden, które pliki lub porcje powinny być częścią zatwierdzenia, przed sfinalizowaniem
operacja. Zobacz sekcję „Tryb interaktywny” w git-dodaj(1), aby dowiedzieć się, jak działać
te tryby.

Opcja --dry-run może być użyta do uzyskania podsumowania tego, co zawiera którykolwiek z plików
powyżej dla następnego zatwierdzenia, podając ten sam zestaw parametrów (opcje i ścieżki).

Jeśli popełnisz zatwierdzenie, a zaraz potem znajdziesz błąd, możesz się z niego wyleczyć
to z odrzutowiec zresetuj.

OPCJE

-a, --wszystko
Powiedz poleceniu, aby automatycznie umieszczał pliki, które zostały zmodyfikowane i usunięte, ale
nie ma to wpływu na nowe pliki, o których nie powiedziałeś Gitowi.

-p, --poprawka
Skorzystaj z interaktywnego interfejsu wyboru poprawek, aby wybrać zmiany do zatwierdzenia. Widzieć
git-dodaj(1) szczegóły.

-C , --reuse-message=
Weź istniejący obiekt zatwierdzenia i ponownie użyj komunikatu dziennika i autorstwa
informacje (w tym znacznik czasu) podczas tworzenia zatwierdzenia.

-C , --reedit-message=
Jak -C, ale z -c wywoływany jest edytor, aby użytkownik mógł dalej edytować plik
zatwierdzić wiadomość.

--poprawka=
Skonstruuj wiadomość zatwierdzenia do użycia z rebase --autosquash. Komunikat zatwierdzenia będzie
być wierszem tematu określonego zatwierdzenia z przedrostkiem „fixup!”. Widzieć git-
przebazować(1) szczegóły.

--squash=
Skonstruuj wiadomość zatwierdzenia do użycia z rebase --autosquash. Komunikat zatwierdzenia
wiersz tematu jest pobierany z określonego zatwierdzenia z przedrostkiem „squash!”. Może być
używany z dodatkowymi opcjami komunikatu zatwierdzenia (-m/-c/-C/-F). Widzieć git-rebase(1) dla
detale.

--reset-autor
W przypadku użycia z opcjami -C/-c/--amend lub podczas zatwierdzania po konflikcie
cherry-pick, zadeklaruj, że autorstwo wynikowego zatwierdzenia należy teraz do
sprawca. Spowoduje to również odnowienie znacznika czasu autora.

--niski
Wykonując próbę, podaj dane wyjściowe w skróconym formacie. Widzieć status git(1) dla
Detale. Implikuje --przebieg próbny.

--Oddział
Pokaż oddział i informacje o śledzeniu nawet w krótkim formacie.

--porcelana
Wykonując próbę próbną, podaj wynik w formacie gotowym do porcelany. Widzieć status git(1)
dla szczegółów. Implikuje --przebieg próbny.

--długie
Wykonując próbę, podaj dane wyjściowe w długim formacie. Implikuje --przebieg próbny.

-z, --null
Podczas wyświetlania stanu zwarcia lub porcelany zakończ wpisy w wyjściu stanu
z NUL zamiast LF. Jeśli nie podano formatu, implikuje format wyjściowy --porcelain.

-F , --plik=
Pobierz komunikat zatwierdzenia z podanego pliku. Używać - przeczytać wiadomość od
standardowe wejście.

--autor=
Zastąp autora zatwierdzenia. Określ jawnego autora, używając standardowego AU Thor
<[email chroniony]> sformatować. W przeciwnym razie zakłada się, że jest wzorcem i jest używany
aby wyszukać istniejące zatwierdzenie tego autora (tj. rev-list --all -i
--autor= ); autor zatwierdzenia jest następnie kopiowany z pierwszego znalezionego zatwierdzenia.

--data=
Zastąp datę autora używaną w zatwierdzeniu.

-m , --wiadomość=
Wykorzystaj podane jako komunikat zatwierdzenia. Jeśli podano wiele opcji -m, ich
wartości są łączone jako osobne akapity.

-T , --szablon=
Podczas edycji komunikatu zatwierdzenia uruchom edytor z zawartością podanego pliku.
Zmienna konfiguracyjna commit.template jest często używana do nadania tej opcji
pośrednio do polecenia. Mechanizm ten może być wykorzystany przez projekty, które chcą kierować
uczestnikom podpowiedzi, co iw jakiej kolejności napisać w wiadomości. jeśli
użytkownik wyjdzie z edytora bez edytowania wiadomości, zatwierdzenie zostanie przerwane. To nie ma
efekt, gdy wiadomość jest przekazywana w inny sposób, np. za pomocą opcji -m lub -F.

-s, --podpis
Dodaj linię Signed-off-by przez osobę zatwierdzającą na końcu komunikatu dziennika zatwierdzenia. The
znaczenie podpisu zależy od projektu, ale zazwyczaj poświadcza to osoba zatwierdzająca
ma prawa do przesłania tej pracy na tej samej licencji i wyraża zgodę na Dewelopera
Świadectwo pochodzenia (zob http://developercertificate.org/ po więcej informacji).

-n, --no-zweryfikuj
Ta opcja omija haki pre-commit i commit-msg. Zobacz też githooki(5).

--pozwól-puste
Zwykle rejestrowanie zatwierdzenia, które ma dokładnie to samo drzewo, co jego jedyne zatwierdzenie nadrzędne, to a
błąd, a polecenie uniemożliwia dokonanie takiego zatwierdzenia. Ta opcja omija
bezpieczeństwa i jest przeznaczony głównie do użytku przez obce skrypty interfejsu SCM.

--zezwalaj na pustą wiadomość
Podobnie jak --allow-empty to polecenie jest przeznaczone głównie do użytku przez obce skrypty interfejsu SCM.
Pozwala na utworzenie zatwierdzenia z pustym komunikatem zatwierdzenia bez użycia hydrauliki
polecenia takie jak git-commit-drzewo(1).

--czyszczenie=
Ta opcja określa, w jaki sposób dostarczony komunikat zatwierdzenia powinien zostać wcześniej oczyszczony
zobowiązanie się. The może to być pasek, spacja, dosłowność, nożyczki lub domyślny.

rozebrać się
Usuń wiodące i końcowe puste wiersze, końcowe spacje, komentarze i
zwijaj kolejne puste wiersze.

Biała przestrzeń
To samo co pasek, z wyjątkiem tego, że #komentarz nie jest usuwany.

dosłownie
Nie zmieniaj w ogóle wiadomości.

nożyczki
To samo co białe znaki, z tą różnicą, że wszystko z (włącznie) wiersza „#
------------------------ >8 ------------------------ " jest obcinany, jeśli wiadomość
ma być edytowany. „#” można dostosować za pomocą core.commentChar.

domyślnym
To samo co pasek, jeśli wiadomość ma być edytowana. W przeciwnym razie odstępy.

Wartość domyślna może zostać zmieniona przez zatwierdzenie.czyszczenie zmienna konfiguracyjna (zob git-
config(1)).

-e, --edit
Wiadomość pobrana z pliku z opcją -F, wiersza poleceń z opcją -m iz obiektu zatwierdzenia z opcją
-C są zwykle używane jako niezmodyfikowany komunikat dziennika zatwierdzenia. Ta opcja pozwala dalej
edytuj wiadomość zaczerpniętą z tych źródeł.

--bez edytowania
Użyj wybranej wiadomości zatwierdzenia bez uruchamiania edytora. Na przykład zatwierdzenie git
--amend --no-edit zmienia zatwierdzenie bez zmiany jego komunikatu o zatwierdzeniu.

--poprawiać
Zastąp końcówkę bieżącej gałęzi, tworząc nowe zatwierdzenie. Zarejestrowane drzewo jest
przygotowany jak zwykle (w tym efekt opcji -i i -o oraz explicit
pathspec), a komunikat z oryginalnego zatwierdzenia jest używany jako punkt wyjścia,
zamiast pustego komunikatu, gdy z wiersza poleceń nie podano żadnego innego komunikatu
poprzez opcje takie jak -m, -F, -c itd. Nowe zatwierdzenie ma tych samych rodziców i autora co
bieżący (opcja --reset-author może to cofnąć).

Jest przybliżonym odpowiednikiem dla:

$ git reset --soft HEAD^
$ ... zrób coś innego, aby wymyślić odpowiednie drzewo ...
$ git zatwierdzenie -c ORIG_HEAD

ale może być użyty do zmiany zatwierdzenia łączenia.

Powinieneś zrozumieć implikacje przepisania historii, jeśli zmienisz to zatwierdzenie
został już opublikowany. (Zobacz sekcję „ODZYSKIWANIE OD PONOWNEJ BAZY UPSTREAM” w git-
przebazować(1).)

--no-post-przepisywanie
Omiń hak po przepisaniu.

-Zawieram
Przed dokonaniem zatwierdzenia dotychczas przygotowanej zawartości należy przygotować zawartość ścieżek
podane również w wierszu poleceń. To zwykle nie jest to, czego chcesz, chyba że jesteś
zawarcie sprzecznej fuzji.

-o, -tylko
Dokonaj zatwierdzenia, pobierając zaktualizowaną zawartość drzewa roboczego ze ścieżek określonych na
wiersza poleceń, pomijając wszelkie treści, które zostały umieszczone w innych ścieżkach.
Jest to domyślny tryb działania odrzutowiec popełnić jeśli podano jakieś ścieżki w pliku
linii poleceń, w takim przypadku tę opcję można pominąć. Jeśli ta opcja jest określona
Wraz z --poprawiać, nie trzeba określać ścieżek, których można użyć do zmiany
ostatnie zatwierdzenie bez zatwierdzania zmian, które zostały już przygotowane.

-u[ ], --untracked-files[= ]
Pokaż nieśledzone pliki.

Parametr trybu jest opcjonalny (domyślnie cała kolekcja) i służy do określenia obsługi
nieśledzonych plików; gdy -u nie jest używane, domyślnie jest to normalna, tj. pokaż nieśledzone
pliki i katalogi.

Możliwe opcje to:

· Nie - Nie pokazuj nieśledzonych plików

· normalna - Pokazuje nieśledzone pliki i katalogi

· cała kolekcja - Pokazuje również pojedyncze pliki w nieśledzonych katalogach.

Wartość domyślną można zmienić za pomocą konfiguracji status.showUntrackedFiles
zmienna udokumentowana w git-config(1).

-v, --pełne
Pokaż ujednoliconą różnicę między zatwierdzeniem HEAD a tym, co zostałoby zatwierdzone na dole
szablon wiadomości o zatwierdzeniu, aby pomóc użytkownikowi opisać zatwierdzenie, przypominając, co
zmiany, jakie ma zatwierdzenie. Zauważ, że to wyjście diff nie ma przedrostków
w #. Ta różnica nie będzie częścią komunikatu zatwierdzenia.

Jeśli określono dwukrotnie, pokaż dodatkowo ujednoliconą różnicę między tym, co zostanie zatwierdzone
oraz pliki drzewa roboczego, tj. nieetapowe zmiany w śledzonych plikach.

-q, --cichy
Pomiń komunikat podsumowujący zatwierdzenie.

--próba
Nie twórz zatwierdzenia, ale pokaż listę ścieżek, które mają zostać zatwierdzone, ścieżki z
lokalne zmiany, które pozostaną niezatwierdzone, oraz ścieżki, które nie będą śledzone.

--status
Uwzględnij dane wyjściowe status git(1) w szablonie komunikatu zatwierdzenia, gdy używany jest plik an
redaktorowi, aby przygotował wiadomość zatwierdzenia. Domyślnie włączone, ale można go użyć do nadpisania
zmienna konfiguracyjna commit.status.

--brak statusu
Nie uwzględniaj danych wyjściowych status git(1) w szablonie wiadomości zatwierdzenia podczas używania
edytor, który przygotuje domyślną wiadomość zatwierdzenia.

-S[ ], --gpg-sign[= ]
Zatwierdzenia ze znakiem GPG. Argument keyid jest opcjonalny i domyślnie przyjmuje osobę zatwierdzającą
tożsamość; jeśli jest określony, musi być przyklejony do opcji bez spacji.

--brak-znaku-gpg
Zmienna konfiguracyjna Countermand commit.gpgSign, która jest ustawiona na wymuszanie każdego
zobowiązać się do podpisania.

--
Nie interpretuj kolejnych argumentów jako opcji.

...
Gdy pliki są podawane w wierszu poleceń, polecenie zatwierdza zawartość pliku
nazwanych plików, bez rejestrowania już wprowadzonych zmian. Zawartość tych plików
są również wystawiane dla następnego zatwierdzenia, oprócz tego, co zostało przygotowane wcześniej.

DATA FORMATY

Zmienne środowiskowe GIT_AUTHOR_DATE, GIT_COMMITTER_DATE i opcja --date
obsługuje następujące formaty daty:

Wewnętrzny format Gita
To jest , Gdzie jest liczbą
sekund od epoki UNIX. jest dodatnim lub ujemnym przesunięciem
z UTC. Na przykład CET (czyli 2 godziny do przodu w stosunku do UTC) to +0200.

RFC 2822
Standardowy format wiadomości e-mail opisany w dokumencie RFC 2822, na przykład czwartek, 07 kwietnia 2005 r.
22:13:13 +0200.

ISO 8601
Godzina i data określone w normie ISO 8601, na przykład 2005-04-07T22:13:13. The
parser akceptuje również spację zamiast znaku T.

Note
Dodatkowo część daty akceptowana jest w formatach: RRRR.MM.DD,
MM/DD/RRRR i DD.MM.RRRR.

PRZYKŁADY

Podczas nagrywania własnej pracy zawartość zmodyfikowanych plików w twoim drzewie roboczym jest
tymczasowo przechowywane w obszarze przejściowym zwanym „indeksem”. odrzutowiec Dodaj. Plik może być
powrócił, tylko w indeksie, ale nie w drzewie roboczym, do stanu z ostatniego zatwierdzenia
z git reset HEAD -- , który skutecznie powraca odrzutowiec Dodaj i zapobiega zmianom
do tego pliku z udziału w następnym zatwierdzeniu. Po zbudowaniu stanu być
zatwierdzane przyrostowo za pomocą tych poleceń, git commit (bez żadnego parametru ścieżki)
służy do rejestrowania tego, co zostało do tej pory wystawione. Jest to najbardziej podstawowa forma polecenia.
Przykład:

$ edytuj cześć.c
$ git rm do widzenia.c
$ git dodaj hello.c
$ git zatwierdzenie

Zamiast umieszczać pliki po każdej pojedynczej zmianie, możesz powiedzieć git commit, aby to zauważyło
zmiany w plikach, których zawartość jest śledzona w twoim drzewie roboczym i wykonaj
odpowiednie git add i git rm dla ciebie. Oznacza to, że ten przykład robi to samo, co
wcześniejszy przykład, jeśli nie ma innej zmiany w twoim drzewie roboczym:

$ edytuj cześć.c
$ rm do widzenia.c
$ git zatwierdzenie -a

Polecenie git commit -a najpierw patrzy na twoje drzewo robocze, zauważa, że ​​​​modyfikowałeś
hello.c i usunięto do widzenia.c, a także wykonuje dla ciebie niezbędne git add i git rm.

Po umieszczeniu zmian w wielu plikach możesz zmienić kolejność zapisywania zmian,
podając ścieżki do git commit. Po podaniu nazw ścieżek polecenie dokonuje zatwierdzenia
który rejestruje tylko zmiany wprowadzone w nazwanych ścieżkach:

$ edytuj cześć.c cześć.h
$ git dodaj hello.c hello.h
$ edytuj Makefile
$ git zatwierdzenie pliku Makefile

Powoduje to zatwierdzenie, które rejestruje modyfikację w pliku Makefile. Zmiany zainscenizowane dla
hello.c i hello.h nie są uwzględniane w wynikowym zatwierdzeniu. Jednak ich zmiany są
nie zaginęły — nadal są inscenizowane i jedynie powstrzymywane. Po powyższej sekwencji, jeśli ty
zrobić:

$ git zatwierdzenie

to drugie zatwierdzenie zarejestrowałoby zmiany w hello.c i hello.h zgodnie z oczekiwaniami.

Po fuzji (zainicjowanej przez odrzutowiec łączyć or odrzutowiec Ciągnąć) zatrzymuje się z powodu konfliktów, czysto
połączone ścieżki są już przygotowane do zatwierdzenia dla ciebie, a ścieżki, które są w konflikcie, są
pozostawiony w stanie nienaruszonym. Najpierw musisz sprawdzić, z którymi ścieżkami koliduje odrzutowiec
status a po ręcznym ustaleniu ich w drzewie roboczym umieściłbyś wynik jako
zwykle z odrzutowiec Dodaj:

$ status git | grep niescalony
niepołączony: hello.c
$ edytuj cześć.c
$ git dodaj hello.c

Po rozwiązaniu konfliktów i przygotowaniu wyniku git ls-files -u przestałby wspominać
skonfliktowaną ścieżkę. Kiedy skończysz, uruchom git commit, aby w końcu zarejestrować scalanie:

$ git zatwierdzenie

Podobnie jak w przypadku zapisywania własnych zmian, możesz użyć opcji -a, aby zapisać pisanie. Jeden
różnica polega na tym, że podczas rozpoznawania scalania nie można użyć git commit z nazwami ścieżek do
zmienić kolejność zatwierdzania zmian, ponieważ scalanie powinno być rejestrowane jako a
pojedyncze zatwierdzenie. W rzeczywistości polecenie odmawia uruchomienia po podaniu nazw ścieżek (ale zobacz -i
opcja).

DYSKUSJA

Chociaż nie jest to wymagane, dobrym pomysłem jest rozpoczęcie komunikatu zatwierdzenia od pojedynczego skrótu
(mniej niż 50 znaków) wiersz podsumowujący zmianę, po którym następuje pusta linia, a następnie a
dokładniejszy opis. Tekst do pierwszego pustego wiersza w komunikacie zatwierdzenia to
traktowany jako tytuł zatwierdzenia i ten tytuł jest używany w Git. Na przykład, git-
poprawka formatu(1) zamienia zatwierdzenie w wiadomość e-mail i używa tytułu w wierszu tematu i
reszta zatwierdzenia w ciele.

Git jest do pewnego stopnia niezależny od kodowania znaków.

· Zawartość obiektów blob to niezinterpretowane sekwencje bajtów. Nie ma
kodowanie tłumaczenia na poziomie podstawowym.

· Nazwy ścieżek są zakodowane w postaci C normalizacji UTF-8. Dotyczy to obiektów drzewiastych,
plik indeksu, nazwy referencyjne, a także nazwy ścieżek w argumentach wiersza poleceń,
zmienne środowiskowe i pliki konfiguracyjne (.git/config (zob git-config(1 XNUMX)), gitignore(5)
gitatrybuty(5) i moduły git(5)).

Zauważ, że Git na podstawowym poziomie traktuje nazwy ścieżek po prostu jako sekwencje innych niż NUL
bajtów, nie ma konwersji kodowania nazw ścieżek (z wyjątkiem komputerów Mac i Windows).
Dlatego używanie nazw ścieżek innych niż ASCII będzie w większości działać nawet na platformach i plikach
systemów, które używają starszego rozszerzonego kodowania ASCII. Jednak repozytoria utworzone na
takie systemy nie będą działać poprawnie na systemach opartych na UTF-8 (np. Linux, Mac, Windows)
i wzajemnie. Ponadto wiele narzędzi opartych na Git po prostu zakłada, że ​​nazwy ścieżek są
UTF-8 i nie będzie poprawnie wyświetlać innych kodowań.

· Komunikaty dziennika zatwierdzeń są zwykle kodowane w UTF-8, ale inne rozszerzone kodowania ASCII
są również obsługiwane. Obejmuje to ISO-8859-x, CP125x i wiele innych, ale nie
Kodowanie wielobajtowe UTF-16/32, EBCDIC i CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
itd.).

Chociaż zachęcamy do zakodowania komunikatów dziennika zatwierdzania w formacie UTF-8, zarówno rdzeń, jak i
Git Porcelain został zaprojektowany tak, aby nie wymuszać UTF-8 w projektach. Jeżeli wszyscy uczestnicy a
w konkretnym projekcie wygodniej jest używać starszego kodowania, Git nie zabrania
To. Należy jednak pamiętać o kilku rzeczach.

1. odrzutowiec popełnić i odrzutowiec drzewo zobowiązań wysyła ostrzeżenie, jeśli otrzyma komunikat dziennika zatwierdzenia
nie wygląda jak prawidłowy ciąg UTF-8, chyba że wyraźnie powiesz, że twój projekt używa a
starsze kodowanie. Sposobem na powiedzenie tego jest posiadanie i18n.commitencoding w .git/config
plik, taki jak ten:

[i18n]
kodowanie zatwierdzeń = ISO-8859-1

Obiekty zatwierdzenia utworzone z powyższym ustawieniem rejestrują wartość i18n.commitencoding
w swoim nagłówku kodowania. Ma to pomóc innym osobom, które później na nie spojrzą. Brak
ten nagłówek sugeruje, że komunikat dziennika zatwierdzenia jest zakodowany w UTF-8.

2. odrzutowiec log, odrzutowiec pokazać, odrzutowiec winić i przyjaciele patrzą na nagłówek kodowania zatwierdzenia
obiekt i spróbuj ponownie zakodować komunikat dziennika do UTF-8, chyba że określono inaczej. Ty
może określić żądane kodowanie wyjściowe za pomocą i18n.logoutputencoding w .git/config
plik, taki jak ten:

[i18n]
kodowanie wyjścia logowania = ISO-8859-1

Jeśli nie masz tej zmiennej konfiguracyjnej, wartość i18n.commitencoding wynosi
używany zamiast tego.

Zauważ, że celowo zdecydowaliśmy się nie kodować ponownie komunikatu dziennika zatwierdzenia, gdy zatwierdzenie jest
wykonane, aby wymusić UTF-8 na poziomie obiektu zatwierdzenia, ponieważ ponowne kodowanie do UTF-8 nie jest
koniecznie operacja odwracalna.

ŚRODOWISKO ROLNICZE KONFIGURACJA ZMIENNE

Edytor używany do edycji komunikatu dziennika zatwierdzenia zostanie wybrany z GIT_EDITOR
zmienna środowiskowa, zmienna konfiguracyjna core.editor, środowisko VISUAL
zmienna lub zmienna środowiskowa EDITOR (w tej kolejności). Widzieć git-var(1) szczegóły.

HACZYKI

To polecenie może uruchamiać hooki commit-msg, pre-commit-msg, pre-commit i post-commit.
See githooki(5), aby uzyskać więcej informacji.

Użyj git-commit online, korzystając z usług onworks.net