Parę pytań - git i argumenty Main

0

Szanowni Państwo,
Mam parę takich ogólnych pytań : )

  1. 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źć?

  2. 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?

  3. 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?

3
  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
  3. 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
  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
3

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/

2
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[...]d+Main%28string%5B%5D+args%29

2

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[...]d-args/command-line-arguments

3
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.

4

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.

2

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/[...]e-revert-and-avoid-conflicts/

na gałęzi master

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0