Jak umieścić swoje testy automatyczne na GitHub i co wpisać w plikach Readme.md i .gitignore?
Jeśli chcesz umieścić swoje testy na lokalnym repozytorium GitHub to z pewnością przyda Ci się znajomość pliku .gitignore i pliku readme.
.gitignore– jest to plik, w którym zawieramy informację o tym, które pliki system ma zignorować. Dlaczego zatem nie powinniśmy wszystkiego „commitować”?
- Nie chcemy narzucać innym osobom jak mają pracować i na jakich narzędziach w związku z tym nie będziemy chcieli wrzucać żadnych plików utworzonych automatycznie przez nasze IDE np. IntelliJ’a
- Jeśli mamy projekt w języku kompilowalnym jak np. Java, to nie chcemy aby w repozytorium znalazły się skompilowane pliki, ponieważ utrudni to pracę innym osobom, a także dlatego, że po najmniejszej zmianie te pliki nie będą już aktualne
Readme.md– stanowi dokumentację dla Twojego projektu/repozytorium Jaką rolę odgrywa ta dokumentacja w Githubie?
- Pełni rolę takiej okładki książki dla publicznych repozytoriów, dzięki czemu ktoś może stwierdzić szybko czy znajdzie u Ciebie coś co mu się przyda czy też nie
- Dodatkowo możesz opisać w tym pliku w jaki sposób należy skonfigurować i zbudować projekt i jak np. uruchamiać testy
A po więcej szczegółów takich jak:
- Jak utworzyć nowe repozytorium na GitHubie?
- Jak umieścić swój projekt testów na zdalnym repozytorium?
- Jak skonfigurować plik .gitignore?
- Co wpisać w pliku readme, aby poprawić widoczność swojego repozytorium?
- Jak łatwo edytować plik readme w narzędziu IntelliJ?
- Podstawowe komendy w pracy z git
Zapraszam do filmiku!
Jak utworzyć Pull Request na GitHubie?
Jeżeli chcesz dodać swoje testy z lokalnego repozytorium do głównego repozytorium musisz utworzyć pull request.
- Co to jest Pull Request?
- Jak wygląda Git Flow w pracy developera?
- Jak wygląda Git Flow w pracy testera?
- Jak utworzyć nowy branch?
- Jak utworzyć Pull Request na GitHubie?
- Jak zmienia się stan repozytorium przy pracy nad zadaniem?
Więcej o tym w materiale:
Gitflow – jest to przepływ pracy w gicie. Opisuje sposób w jaki dodaje się nowe funkcje/testy/kod do istniejącego głównego brancha (gałęzi). W przypadku testerów automatycznych, którzy nie wydają żadnego kodu produkcyjnego proces ten jest bardzo uproszczony.
Pull Request – inaczej Merge Request (PR/MR), tworzymy go w celu dodania naszych zmian do głównego brancha. Przykładowo utworzyłeś nowe testy automatyczne i chciałbyś aby były wykonywane w ramach automatycznej regresji na narzędziu CI/CD, w takiej sytuacji wystawiasz pull request, czyli prośbę o dodanie Twoich zmian do głównego brancha. Należy tutaj pamiętać, że ktoś musi zaakceptować Twoją prośbę i nierzadko wiąże się to z koniecznością dodania paru zmian po Twojej stronie, aby kod był czytelniejszy i łatwiejszy w utrzymaniu. W materiale zobaczysz jak przygotować taki pull request na przykładzie dodania nowych testów Selenium.
Poniżej zamieszczam kilka komend w GitHubie, które mogą być dla Ciebie przydatne w codziennej pracy:
git status
- zwraca informację o stanie Twojego repozytorium m.in.:
- Czy jesteś na bieżąco z zdalnym branchem
- Czy masz jakieś nieśledzone pliki (takie które są u Ciebie ale nie ma ich na zdalnym repozytorium)
- Czy masz jakieś niedodane zmiany (czyli dokonałeś zmian w tych plikach, ale jeszcze ich nie zacommitowałeś)
git branch
- Informuje na jakim branchu się znajdujesz
- Wyświetla listę dostępnych lokalnych branchy
git branch <nazwa_branchu>
- Pozwala utworzyć nowy branch lokalny
- Aktualny branch stanowi bazę pod nowo utworzony branch (czyli wszystkie zmiany w branchu aktualnym znajdą się też w nowym)
git checkout <nazwa_branchu>
- Pozwala przepiąć się na wybrany branch (może być zarówno zdalny jak i lokalny)
git pull
- Pobiera najnowsze zmiany dla aktualnego brancha
git add <sciezka>
- Dodanie wybranego pliku lub grupy plików (np. przy pomocy *) do najbliższego commitu
- Dodanie wszystkich plików realizuje się za pomocą kropki tj. „git add .”
git commit -m <wiadomość>
- Tworzy tzw. migawkę zmian w projekcie, które będą przechowywane w pamięci repozytorium, konieczne do umieszczcenia swoich zmian na repozytorium
git push
- Umieszcza wcześniej zadeklarowane zmiany (commity) na repozytorium zdalnym
- W przypadku gdy na repozytorium zdalnym nie ma jeszcze brancha o takiej samej nazwie jak lokalnie konieczne jest użycie polecenia–>
- git push –set-upstream origin <nazwa_brancha>
Jak zwykle zapraszam na kanał na youtubie @tujestbug i na Faceboka po kolejne, świeże materiały
0 komentarzy