Z pewnością sposób wykonania zależy od powłoki. W Bash możesz używać pojedynczych cudzysłowów wokół wiadomości i możesz po prostu pozostawić wycenę otwartą, co spowoduje, że Bash poprosi o kolejny wiersz, dopóki nie zamkniesz cytatu. Lubię to:
git commit -m 'Message
goes
here'
Alternatywnie możesz użyć „dokumentu tutaj” (znanego również jako heredoc):
Odpowiedź Petera Farmera na później wspomina, że konwencja Git jest podobna: 1 wiersz do podsumowania, dwa podziały wiersza, a następnie szczegółowa wiadomość.
@KelvinShadewing, tak, ale z tą różnicą, że reguły zastępowania powłok mają zastosowanie do wiadomości, więc musisz unikać znaków dolara i innych metaznaków. Z drugiej strony pozwala na używanie zmiennych.
@Nikhil, wiele programów obsługuje pojedynczy myślnik jako nazwę pliku, co oznacza stdin lub stdout. Z tutaj dokumencie The gitkomenda może czytać tekst wiadomości ze standardowego wejścia, a -Fopcja podaje nazwę pliku, aby przeczytać wiadomość.
Od man git commit: -m <msg>, --message = <msg> Użyj podanego <msg> jako komunikatu zatwierdzenia. Jeśli podano wiele opcji -m, ich wartości są łączone jako osobne akapity.
Używając Git z linii poleceń w Bash, możesz wykonać następujące czynności:
git commit -m "this is
> a line
> with new lines
> maybe"
Po prostu wpisz i naciśnij, Enterkiedy chcesz nową linię, symbol „>” oznacza, że nacisnąłeś Enteri pojawiła się nowa linia. Inne odpowiedzi również działają.
Odpowiedź Abizerna wyjaśniła mi, dlaczego to działa - powłoka Bash interpretuje naciśnięcie klawisza <kbd> Enter </kbd> jako nowy wiersz, dopóki pierwszy znak podwójnego cudzysłowu nie zostanie „zamknięty” (z kolejnym znakiem podwójnego cudzysłowu).
Muszę się zgodzić, że jest to o wiele bardziej skuteczne, łatwiejsze i praktyczne rozwiązanie niż przyjęta odpowiedź. Działa dobrze dla mnie przy użyciu Git 1.8.2.1. +1 ode mnie
To nie jest specjalna funkcja klawisza Enter , ale raczej związana z cudzysłowami. To, czy używasz podwójnych czy pojedynczych cudzysłowów, nie ma tak naprawdę znaczenia, z wyjątkiem zmiennego rozwijania i znaków specjalnych - dlatego wybrałem pojedyncze cudzysłowy w mojej odpowiedzi.
Słowa w postaci $ „ string ” są traktowane specjalnie. Słowo jest
interpretowane jako ciąg znaków , a znaki specjalne z odwrotnym ukośnikiem są zastępowane zgodnie ze standardem ANSI C.
Obejmuje to obsługę znaków nowej linii, jak pokazano powyżej, a także kody szesnastkowe i Unicode i inne. Przejdź do sekcji połączonej, aby wyświetlić listę znaków, które uniknęły ukośnika.
rsy $ bash --version GNU bash, wersja 3.2.53 (1) -release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc. Dane wyjściowe tego polecenia są, zgodnie z oczekiwaniami, pokazane w dwóch różnych linie!
Nie musisz nawet używać $ '...' dla całego łańcucha; za pomocą tego właśnie wokół znaku nowej linii będzie działać: git commit -m "first line"$'\n'"second line". Pamiętaj, że musisz zamknąć poprzedni ciąg przed rozpoczęciem $'string'.
Spróbuj wykonać następujące czynności, aby utworzyć wieloliniowy komunikat zatwierdzenia:
git commit -m "Demonstrate multi-line commit message in Powershell"-m "Add a title to your commit after -m enclosed in quotes,
then add the body of your comment after a second -m.
Press ENTER before closing the quotes to add a line break.
Repeat as needed.
Then close the quotes and hit ENTER twice to apply the commit."
Następnie sprawdź, co zrobiłeś:
git log -1
Powinieneś skończyć z czymś takim:
Zrzut ekranu pochodzi z przykładu, który skonfigurowałem za pomocą programu PowerShell z Poshgit.
Świetna odpowiedź. Rozglądałem się za tym od wieków i próbowałem wielu różnych sposobów formatowania moich komunikatów Git, ale to działa najlepiej. Mogę potwierdzić, że działa z pytaniem w Git 1.8.2.1.
To powinna być wybrana odpowiedź, ponieważ jest to najbardziej kompatybilna metoda, nie opiera się ona na żadnym konkretnym
1
To lepsza odpowiedź i powinna zostać wybrana jako odpowiedź. Nie tylko jest to zgodne z domyślnym zachowaniem i zapewnia znacznie czystszy komunikat zatwierdzenia, ale jest też nieco bardziej elastyczne z wielokrotnym -m. Mimo że wygląda na specyficzne dla systemu Windows i przyciąga uwagi związane z oknami, działa również dobrze w systemie Linux.
Słowo ostrzeżenia, mam wrażenie, że ogólna konwencja ma mieć linię podsumowania jako pierwszą linię, a następnie dwa podziały linii, a następnie rozszerzony komunikat w komunikacie zatwierdzenia, więc zrobienie czegoś takiego złamałoby tę konwencję. Oczywiście możesz:
Nie ma potrzeby komplikowania rzeczy. Po przejściu -m "text...do następnej linii naciśnij Enter. Po Enternaciśnięciu >pojawia się. Kiedy skończysz, po prostu włóż "i naciśnij Enter:
$ git commit -m "Another way of demonstrating multicommit messages:
>
> This is a new line written
> This is another new line written
> This one is really awesome too and we can continue doing so till ..."
$ git log -1
commit 5474e383f2eda610be6211d8697ed1503400ee42(HEAD -> test2)Author:**************<*********@gmail.com>Date:MonOct913:30:262017+0200Another way of demonstrating multicommit messages:This is a new line written
This is another new line written
This one is really awesome too and we can continue doing so till ...
Używam zsh na Macu i mogę wysyłać wiadomości zatwierdzające w wielu wierszach w ramach podwójnych cudzysłowów ("). Zasadniczo ciągle piszę i naciskam klawisz Return, aby uzyskać nowe wiersze, ale wiadomość nie jest wysyłana do Gita, dopóki nie zamknę cytatów i nie wrócę .
Możesz także poinstruować Git, aby używał dowolnego edytora do edycji wiadomości zatwierdzenia. Z dokumentów na temat git-commit :
Edytor używany do edycji komunikatu dziennika zatwierdzenia zostanie wybrany ze
GIT_EDITORzmiennej środowiskowej, zmiennej core.editorkonfiguracyjnej, zmiennej VISUALśrodowiskowej lub EDITOR
zmiennej środowiskowej (w tej kolejności). Zobacz git-var, aby uzyskać szczegółowe informacje.
Osobiście uważam, że najłatwiej jest modyfikować komunikaty zatwierdzania po fakcie vi(lub jakimkolwiek innym edytorze git), a nie w wierszu poleceń, robiąc to git commit --amendzaraz po git commit.
Dlaczego więc ktoś głosował za tym? Jest to najwygodniejszy sposób pracy z poleceniami wielowierszowymi w bash, wystarczy tylko raz go skonfigurować. Korzystałem z innych głupich sugestii pokazanych w innych odpowiedziach tutaj, ale kiedy nauczysz się edytować swoje polecenia w swoim ulubionym edytorze tekstów, nie ma już odwrotu.
Oto lista wadliwych rozwiązań w systemie Windows ze standardową powłoką cmd.exe (aby zaoszczędzić trochę czasu na próby i błędy!):
git commit -m 'HelloEnter nie działa: nie poprosi o nową linię
git commit -m "HelloEnter ten sam
git commit -m "Hello^Enter ten sam
git commit -m 'Hello^EnterWorld'wygląda na działający, ponieważ pyta „Więcej?” i pozwala napisać nową linię, ale w końcu git logzobaczysz, że jest to nadal wiadomość jednowierszowa ...
TL; DR: Nawet jeśli w systemie Windows parsowanie wiersza poleceń działa inaczej i ^umożliwia wprowadzanie danych wielowierszowych, tutaj nie pomaga.
Wreszcie git commit -ejest prawdopodobnie najlepszą opcją.
Niestety, git wydaje się nie dopuszczać znaku nowej linii w swoim komunikacie. Istnieją już różne rozsądne rozwiązania, ale przy skryptowaniu są denerwujące. Tutaj dokumenty również działają, ale mogą być również zbyt denerwujące, aby sobie z nimi poradzić (pomyśl o plikach yaml)
Chociaż jest to nadal brzydkie, pozwala na stosowanie „jednowarstwowych”, które mogą być nadal przydatne. Ponieważ zwykle łańcuchy są zmienne lub łączone ze zmiennymi, brzydoty można ograniczyć do minimum.
Nie widzę nikogo, kto wspomniałby, że jeśli nie podasz wiadomości , otworzy się dla ciebie nano (przynajmniej w Linuksie), w którym możesz napisać wiele wierszy ...
Używamy plików cookie i innych technologii śledzenia w celu poprawy komfortu przeglądania naszej witryny, aby wyświetlać spersonalizowane treści i ukierunkowane reklamy, analizować ruch w naszej witrynie, i zrozumieć, skąd pochodzą nasi goście.
Kontynuując, wyrażasz zgodę na korzystanie z plików cookie i innych technologii śledzenia oraz potwierdzasz, że masz co najmniej 16 lat lub zgodę rodzica lub opiekuna.