Parę pytań - git i argumenty Main

1. Podobno dobry kod dokumentuje się sam :)
2. Możesz zrobić revert tych dwóch commitów, ewentualnie zrobić git reset lokalnie i wypushować brancha na zdalne repozytorium np. tak:

git reset --hard <commit-hash>
 git push -f origin master

1. To nie jest pętla tylko główna metoda aplikacji odpalana w każdej aplikacji C#, nie tylko konsolowej. Args to są argumenty, które możesz przekazać odpalając np. apkę z konsoli wpisująć Aplikacja.exe ARG1 ARG2 i wtedy masz w tej tablicy dwa stringi: "ARG1" i "ARG2".

1. Poza konsola w (nie chcę skłamać) skrótach aplikacji masz czasami dodatkowe argumenty. Wramach developmentu to się przydaje żeby np. za każdym razem nie wpisywać Longina i hasla

Zakomitowałem i zpushowałem repo na gita. Zacząłem od miniprojektu w ramach nauki. Jak powinna wyglądać dokumentacja do projektu na gicie? Są jakieś standardy opisywania projektu, albo jak to zrobić >najczytelniej? Tak, żeby ktoś (np. Rekruter) wszedł na naszego githuba i od razu wiedział o co chodzi i mógł się w projekcie odnaleźć?

https://www.makeareadme.com/

gornada napisał(a):

1. Takie głupie pytanie. Za każdym razem tworząc nowy projekt konsolowy powstaje metoda "static void Main(string[] args)". Czym są owe "string[] args" i co one nam dają? Przecież pętla Main jest wywoływana automatycznie i nie przyjmuje żadnych parametrów?

Masz rację. Głupie.
Po pierwsze Main nie jest pętlą.
Po drugie https://www.google.com/search?client=firefox-b-d&q=static+void+Main%28string%5B%5D+args%29

1. Daj readme.md w formacie Markdown
2. Wymuskana historia komitów może być podejrzana, zależy kto patrzy. Ja bym pomyślał patrząc na taką "nuda, pewnie robił tutorial".
3. To są argumenty podane do programu z konsoli
   https://docs.microsoft.com/pl-pl/dotnet/csharp/programming-guide/main-and-command-args/command-line-arguments

gornada napisał(a):

1. Powiedzmy, że popełniłem modyfikację w repo na gałęzi master. Po kilku dniach i, powiedzmy, dwóch komitach zauważyłem, że ta modyfikacja jest błędna. Jak cofnąć się za pomocą gita o dwa komity w projekcie i usunąć te dwa które opierały się na złych założeniach?

Ale po co? Nie lepiej zrobić nowego commita i w nim naprawić błąd?

1. Takie głupie pytanie. Za każdym razem tworząc nowy projekt konsolowy powstaje metoda "static void Main(string[] args)". Czym są owe "string[] args" i co one nam dają? Przecież pętla Main jest wywoływana automatycznie i nie przyjmuje żadnych parametrów?

Jak to nie przyjmuje, skoro sam wkleiłeś kod, w którym przyjmuje?

Wywołaj w konsoli: mojprogram.exe foo bar i będziesz miał foo i bar w args.

A co jeśli mamy kod na kilka set linijek i połowa z tego jest błędna? Tak, że łatwiej cofnąć się do wersji z przed kilku dni gdzie jeszcze nie było tego błędu?

To trzeba go naprawić. Myślisz, że jak nad kodem pracuje kilka-kilkanaście osób, to resetują główną gałąź o kilka dni, a potem wszyscy na nowo merdżują swoją pracę z kilku dni? To wcale nie jest łatwiejsze, wręcz przeciwnie. Publicznej historii się nie cofa, nie resetuje i nie psuje.

W gicie tylko dokładamy nowe commity które są listą zmian od poprzedniego commita. Żeby coś cofnąć po prostu odwracasz zmiany (revert) i dokładasz na koniec, będziesz miał 2 dodatkowe commity, ale tak to działa żeby osoby które pobrały kod po tym pierwszym mogły pracować dalej.
W zasadzie da się cofać, ale powinieneś to robić tylko na lokalnych zmianach, nigdy nie wycofuj zmian które już wypchnąłeś na serwer (push)

A co jeśli mamy kod na kilka set linijek i połowa z tego jest błędna? Tak, że łatwiej cofnąć się do wersji z przed kilku dni gdzie jeszcze nie było tego błędu?

normalnie kod tworzymy na osobnym branchu, a dopiero gdy jest sprawdzony i działający, tworzymy Pull request, inna osoba go przegląda i merge'uje do głównego brancha. Nie powinno się to w ogóle zdarzyć że połowa kodu jest błędna, ale jeśli jest to możesz po prostu odwrócić merge twojego brancha. Jeśli chcesz wtedy dalej pracować nad tym kodem w poprzednim branchu to nie będziesz mógł zmergować nowego kodu bez konfliktów bo na głównej gałęzi kod został wycofany. Najłatwiej zrobić revert reverta tak żeby historia szła dalej. https://blog.theodo.com/2016/11/revert-the-revert-and-avoid-conflicts/

na gałęzi master

#BLM!
Już nie używamy "master" bo się źle kojarzy tylko "main" - https://github.com/github/renaming