In früheren Tutorials haben wir gelernt, wie die Verwaltung von Repositorys in lokalen Umgebungen durchgeführt wird, und dies ist nicht schlecht, wenn wir lernen, wie man Git verwendet . In der Arbeitswelt wird es jedoch auf andere Weise gehandhabt, und die meiste Zeit müssen wir an einem Repository arbeiten remote, das mehrere Zweige hat und jeder Entwickler, der im selben Upload vorhanden ist, ändert sich ständig.

Remote-Repositorys

Ein Remote-Repository gehört nicht zu uns und kann sich auf einem Server in der Cloud, auf einem Computer eines anderen Entwicklers oder sogar in einem Dateisystem befinden. Die Hauptfunktion dieser Repositorys besteht darin, dass andere Entwickler mit ihr zusammenarbeiten können, einschließlich uns über Zweigniederlassungen oder Zweigniederlassungen .

Es gibt viele Dienste, mit denen wir unser Remote-Repository erstellen können. GitHub ist jedoch auf persönliche Projekte und die Zusammenarbeit zwischen der Entwickler-Community und bestimmten Projekten ausgerichtet. Bitbucket ist auf private Projekte und Arbeitsteams in Unternehmen oder Organisationen ausgerichtet.

Für dieses Tutorial verwenden wir Bitbucket , es ist kostenlos und es ähnelt am ehesten der Arbeitsphilosophie, auf die wir uns konzentrieren möchten.

Erstellen des Remote-Repository

Wir haben erwähnt, dass ein Remote-Repository nicht zu uns gehört, da es sich auf einer Plattform befindet, die uns nicht gehört. Wir können jedoch Vorgänge auf dieser Plattform ausführen, von der Erstellung bis zum Löschen, wenn wir dies wünschen.

Um unser Remote-Repository zu erstellen, rufen wir die Seite Bitbucket auf. Wenn wir nicht registriert sind, erstellen wir unser Konto, geben es ein und suchen in unserem Hauptfenster nach der Option Erstellen , um das Remote-Repository zu erstellen.

Wir geben unserem Repository den Namen, wir fügen eine Beschreibung hinzu, wir wählen die Sichtbarkeit und die Möglichkeit, Gabeln zu erstellen, wo wir auch die Sprache auswählen können, auf der unser Projekt basieren soll. Schließlich drücken wir create und wir lassen unser Remote-Repository erstellen.

Wir gehen davon aus, dass wir bei Null anfangen und kein Projekt haben, aber bald beginnen werden, unsere Änderungen hochzuladen. Dazu müssen wir den Ordner erstellen, in dem sich das Projekt befindet, und den ersten Push ausführen.

Dazu erstellen wir einen Ordner und öffnen darin eine Kommandokonsole und initialisieren sie als Git- Repository. Danach stellen wir die Verbindung zu unserem Remote-Repository her, das sich im Hauptfenster unseres Repositorys befindet neu erstellt:

Jetzt müssen wir unseren ersten Push durchführen, um zu überprüfen, ob alles korrekt funktioniert. Dazu erstellen wir eine neue Datei, die eine TXT-Datei mit einem einfachen Text sein kann. Wir verwenden den Befehl add , um es dem Repository hinzuzufügen, fügen unser erstes Commit hinzu und senden es schließlich an den Hauptzweig:

Wie wir sehen, verlief alles reibungslos, jedoch können Benutzer, die sich beim Starten des Tools etwas unsicher fühlen und sich fragen, ob die Dateien hochgeladen wurden, das Repository in Bitbucket aktualisieren und die vorgenommenen Änderungen anzeigen :

Bitbucket ist äußerst nützlich. Es ermöglicht uns nicht nur, Repositorys zu erstellen, sondern seine Webanwendung ermöglicht es uns, Daten wie den Zweig im Repository, die erstellten Gabeln und die darin enthaltenen Aktivitäten anzuzeigen und sogar Einladungen für andere Entwickler zu senden.

Arbeiten mit dem Remote-Repository

Sobald wir unser Repository erstellt haben, ist es Zeit, mit der Zusammenarbeit zu beginnen. Das erste, was wir tun müssen, ist, Zweige oder Zweige zu erstellen. Neben dem Hauptzweig müssen wir für das Projekt im Allgemeinen einen zusätzlichen Zweig erstellen, in dem die Entwickler ihre endgültigen Änderungen zusammenführen und hochladen.

Wir werden den Zweig namens ” development” und einen persönlichen Zweig für unsere Änderungen erstellen. Dazu verwenden wir den Befehl ” branch”, gefolgt vom Namen des Zweigs. Schauen wir uns an, wie er in unserer Konsole aussieht:

Dadurch werden unsere Zweige lokal erstellt, aber bis wir Änderungen daran vornehmen und den Push ausführen, werden wir nicht in unserem Repository registriert. Dazu wechseln wir mit dem Befehl checkout in unseren persönlichen Zweig und bestätigen mit dem Status, dass wir nichts zu tun haben . Dies sollte so aussehen, da es sich um einen neuen Zweig handelt.

Jetzt werden wir Ordner und einige Dateien erstellen, um unserem Projekt Gewicht zu verleihen. Wir erinnern uns jedoch, dass die Änderungen in unserer Branche vorgenommen werden. Nachdem wir diese Operationen ausgeführt haben, müssen wir dasselbe mit add hinzufügen , das entsprechende Commit ausführen und schließlich den Push an unseren Zweig senden. Sehen wir uns diese Operationen in unserer Befehlskonsole an:

Wir haben bereits den Upload in unseren Zweig gemacht, jetzt müssen wir nur noch dasselbe mit dem Entwicklungszweig machen, aber dafür ist es nicht erforderlich, den Befehl add oder commit zu verwenden. Dazu werden wir den Befehl merge verwenden , um die Änderungen zu verbinden, die in der nicht vorhanden sind Dies erspart uns viel Arbeit und ermöglicht uns die Kontrolle über die Aktionen, die wir im Repository ausführen.

Dazu müssen wir mit dem Befehl checkout in den Entwicklungszweig wechseln und dort den Befehl merge ausführen, der auf den Jacosta-Zweig verweist, um die vorgenommenen Änderungen zu übernehmen.

Mit dieser Aktion wird das Update durchgeführt. Dies bedeutet jedoch nicht, dass wir die Änderungen in der Filiale auf die gleiche Weise hochgeladen haben, wie wir den Push ausführen müssen. Dies ermöglicht uns jedoch, einige zusätzliche Schritte zu speichern und den Vorgang für den Upload zu vereinfachen. Diese Aktion erstellt den neuen Zweig und vereinheitlicht unsere Änderungen. Wenn wir weiterhin nicht vertrauen, was die Konsole uns mitteilt, können wir zu Bitbucket gehen, wo wir die neu erstellten Zweige sowie die Aktionen sehen, die wir im Abschnitt mit den letzten Aktivitäten durchgeführt haben:

Wie wir sehen können, haben wir die neuen Zweige sowie die neuen Änderungen vorgenommen. Es ist wichtig zu erwähnen, dass dies der normale Workflow ist, den wir ausführen müssen, wenn wir in kollaborativen Umgebungen arbeiten. Andernfalls würden Konflikte dazu führen, dass unser Team sogar einige Stunden damit verbringt, die Probleme des Repositorys zu lösen.

Klonen des Remote-Repository

Was wir gerade als Teil der Idee gesehen haben, dass wir diejenigen waren, die das Remote-Repository erstellt haben, aber im Moment sind wir zu einigen Änderungen des Prozesses eingeladen. Wir gehen davon aus, dass unser Team auch Bitbucket verwendet und das Repository auf der Plattform erstellt hat. Wir gehen zum Hauptfenster und suchen die Option Klonen. Wenn wir darauf klicken, sehen wir die genaue Zeile, in der diese Aktion ausgeführt wird, die uns genau klont, was sich im Repository befindet In diesem Moment:

Wir haben erwähnt, dass diese Aktion genau das klont oder kopiert, was sich zu diesem Zeitpunkt im Repository befindet. Es kann jedoch vorkommen, dass einige Entwickler eine kurzfristige Änderung hochladen und diese nicht im Klon enthalten ist, sodass sie nicht in der Kopie enthalten ist das werden wir in unserer Maschine haben.

Letzte Tipps

Abschließend ist zu erwähnen, dass Git es uns zwar ermöglicht, die Kontrolle über unser Projekt und unsere Dateien zu übernehmen und die Änderungen im Entwicklungsteam zu vereinheitlichen, es jedoch kein Werkzeug ist, das wir nur für die Verwaltung von Projekten verwenden können.

Wir empfehlen, es mit Anwendungen wie Asana oder Trello von Hand zu nehmen, um sicherzustellen, dass unsere Projekte an allen Fronten abgedeckt sind. Auf diese Weise wissen wir, dass diese immer die neuesten Änderungen aufweisen und dass die dafür festgelegten Daten und Verpflichtungen unbedingt eingehalten werden .

Damit haben wir dieses Tutorial abgeschlossen, in dem wir unser Remote-Repository mit Bitbucket erstellen und darüber hinaus den gesamten Workflow anzeigen konnten, der für eine optimale Verwaltung erforderlich ist, wenn wir in einer kollaborativen Entwicklungsumgebung arbeiten.