Ich bin noobishly neu im Git-Versionskontrollsystem, nachdem ich Tortoise Svn, VSS verwendet habe. Ich dachte daran, meinen Code als Open-Source-Arbeit auf github [Moving by Crowds Voice] beizusteuern, ich habe ein Konto eröffnet und ein Repository für das Projekt erstellt. Erst später wusste ich, dass die Anfänger tuts/Erste Schritte auf Github die Befehlszeile verwendeten und Mann, das ist nicht die Art, wie ich das Quellcodeverwaltungssystem mochte. Also machte ich mich auf den Weg zu SO, um Antworten zu erhalten. Ich bekam viele und gab mir eine Erweiterungs-GUI für die Verwaltung aber immer noch Was als nächstes? Wie gebe ich mein neues Projekt über Gui an Git weiter und was ist mit der Readme-Datei, muss es sich wirklich um eine ReadMe.MDDatei handeln? Die Art des Projekts sind benutzerdefinierte Extender, benutzerdefinierte Steuerelemente auf asp.net (c #). Ich möchte, dass die Leute die DLL herunterladen [Endergebnis des Projekts]aber ich sollte derjenige sein, der entscheidet, wer sich mir in dem projekt anschließt, und ich denke, das ist es, was github mit Private Repositories [None for free account] meint. Meine Frage läuft also auf zwei Punkte hinaus:
Muss diese Art von Projekt ein privates Repository sein? [kein Vorschlag/keine Umfrage, ich möchte, dass mir jemand die Probleme und Vorteile bei der Durchführung einer solchen Sache mitteilt]
Wie fange ich an, Google hat mir keine vollständigen Antworten darauf gegeben. Es gibt überall Bits mit wenig Informationen. Geben Sie mir eine Quelle
Als erstes würde ich empfehlen, sich "Linus Torvalds on Git" anzuschauen , einen Google Tech Talk des Git-Erstellers. Es ist eine Stunde lang, aber es ist eine wunderbare Einführung in die Philosophie hinter der verteilten Versionskontrolle, insbesondere Git. Es ist keine Anleitung, und es ist nicht einmal besonders technisch. Es geht eigentlich hauptsächlich um Projektmanagement, und es ist ziemlich unterhaltsam.
Das zu verstehende Kernprinzip ist , dass jeder seine eigene Kopie des Repositorys hat . Personen arbeiten zusammen, indem sie Änderungssätze senden und empfangen. Das Abrufen einer Reihe von Änderungen von jemandem und das Einfügen in Ihr Repository wird als "Pullen" bezeichnet. Das Senden einer Reihe von Änderungen von Ihrem Repository zu einem anderen wird als "Pushen" bezeichnet.
Muss diese Art von Projekt ein privates Repository sein?
Bei einem kostenlosen GitHub-Konto sind der Quellcode Ihres Projekts und sein Verlauf öffentlich und für jeden einsehbar. Jeder kann auf die Schaltfläche „Fork“ klicken und eine eigene Kopie Ihres GitHub-Projekts erstellen. Ihre Kopie wird deutlich als Fork Ihres Originals gekennzeichnet. (Schauen Sie sich zum Beispiel die obere linke Ecke dieser Seite an, dort steht „daxelrod/pod-pseudopod“ und darunter „forked from allisonrandal/pod-pseudopod“.)
Standardmäßig sind Sie die einzige Person, die Änderungen an Ihrer Kopie des Projekts übermitteln kann. Wenn jemand anderes eine Verbesserung an seiner Kopie des Projekts vorgenommen hat, kann er Ihnen einen Pull-Request senden ; Das heißt, eine Bitte, dass Sie ihre Verbesserung in Ihre Kopie des Projekts integrieren. Es ist allein Ihre Entscheidung, ob Sie einen Pull-Request akzeptieren.
Als Administrator Ihrer Kopie des Repositorys können Sie bei Bedarf Mitbearbeiter hinzufügen. Ein Mitarbeiter ist eine bestimmte Person, der Sie vertrauen, dass sie Änderungen direkt an Ihrer Kopie des Projekts übermittelt. Dies ist völlig optional, und die meisten GitHub-Projekte haben keine Mitarbeiter; sie akzeptieren einfach Pull-Requests.
Ein kostenpflichtiges GitHub-Konto gibt Ihnen die Möglichkeit, private Repositories zu erstellen. Ein privates Repository ist nur von bestimmten Personen, die Sie als private Mitarbeiter ausgewählt haben, einsehbar und forkbar.
Was ist mit der Readme-Datei? Muss es sich wirklich um eine ReadMe.MD-Datei handeln?
Es reicht aus, eine reine Textdatei namens README zu übergeben . Wenn Sie Lust auf Formatierung haben, können Sie eine README.md-Datei erstellen und Markdown darin verwenden; Dieselbe Syntax, die Sie zum Formatieren von Stack Overflow-Fragen verwenden.
Google hat mir keine vollständigen Antworten darauf gegeben, da sind überall Bits mit wenig Informationen drin. Geben Sie mir eine Quelle
Erlauben Sie mir, für einen Moment etwas zu redigieren. Git ist im Grunde ein Befehlszeilenprogramm, und daher handelt es sich bei den meisten Referenzen, die Sie sehen werden, um die Interaktion mit ihm über die Befehlszeile. Ich persönlich empfehle Ihnen, Git über die Befehlszeile zu lernen. Auf diese Weise verstehen Sie, was vor sich geht, und können den Großteil der Hilfe und Dokumentation nutzen. Ich empfehle die Verwendung einer GUI erst, wenn Sie wissen, wie man Git von der Befehlszeile aus verwendet.
Wenn Sie Befehlszeilen-Git lernen möchten, ist Pro Git eine fantastische Ressource. Es ist entweder als Buch oder kostenlos online erhältlich. Ehrlich gesagt kann es eine gute Einführung in die Konzepte und Arbeitsabläufe sein, auch wenn Sie kein Befehlszeilen-Git lernen.
Wenn Sie jedoch auf einer GUI bestehen, werfen Sie einen Blick auf An Illustrated Guide to Git on Windows , das git-gui verwendet. Wenn Sie dies tun, lassen Sie sich bitte nicht von Dokumentationen oder Tutorials abschrecken, die die Befehlszeile verwenden ! Ihre Prinzipien gelten immer noch, außer dass Sie auf Befehle klicken, anstatt sie einzugeben. (Und ja, ich weiß, das ist eine zu starke Vereinfachung.)
Ihr anfänglicher GitHub-Workflow zum Erstellen eines Projekts, Festschreiben Ihrer ersten Änderung und Pushen wird hier detailliert beschrieben – wiederum mit Befehlszeilenanweisungen. Die Grundidee ist, dass Sie ein Repository auf GitHub und einen Klon davon auf Ihrer lokalen Festplatte haben. Sie übertragen Änderungen an Ihr lokales Repository und pushen sie dann zu dem auf GitHub, wenn Sie bereit sind, sie zu teilen.
I create a local read-me and push it to repooder
umgekehrt
daxelrod
Deeptechn
daxelrod