Programista zmodyfikował plik, który jest już śledzony przez Git. Którego polecenia powinien użyć, aby przygotować ten plik (dodać zmiany do poczekalni - ang. staging area) do następnego commita?

Poprawna odpowiedź: A

Uzasadnienie i szersze wyjaśnienie:

Cykl pracy z Gitem składa się z trzech głównych obszarów: katalogu roboczego, poczekalni (staging area) i historii repozytorium. Polecenie git add <nazwa_pliku> jest kluczowym narzędziem do przenoszenia zmian z pierwszego obszaru do drugiego.

• git add <nazwa_pliku> pobiera aktualny stan pliku z katalogu roboczego i umieszcza go w poczekalni (staging area). Jest to jawny krok, w którym programista decyduje, które konkretnie zmiany mają zostać włączone do następnego commita. Polecenie to służy zarówno do śledzenia nowych plików, jak i do dodawania zmodyfikowanych, już śledzonych plików do poczekalni.

Dlaczego pozostałe odpowiedzi są nieprawidłowe?

• B. git commit -m "opis": To polecenie pobiera pliki, które są już w poczekalni, i trwale zapisuje je w historii repozytorium jako nowy commit. Jest to krok następujący po git add.
• C. git push: Służy do wysyłania zatwierdzonych (za pomocą commit) zmian z lokalnego repozytorium do repozytorium zdalnego (np. na GitHub). Jest to operacja synchronizacji, a nie przygotowywania zmian.
• D. git status: To polecenie diagnostyczne, które pokazuje stan plików w katalogu roboczym i poczekalni (informuje, które pliki są zmodyfikowane, które są w poczekalni itp.), ale samo w sobie nie zmienia tego stanu, a reszta składni jest nieprawdziwa.