Ankündigung
Einklappen
Keine Ankündigung bisher.
Start Setup eines neuen PHP Projektes
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zitat von ChromOxid Beitrag anzeigenSpätestens hier würde mich die Begründung sehr interessieren.
Gruss
ClausPre-Coffee-Posts sind mit Vorsicht zu geniessen!
Kommentar
-
Zitat von Thallius Beitrag anzeigen
Wenn er wirklich nur als Einzelkämpfer unterwegs ist, dann macht GIt auch nicht wirklich Sinn. Ob ich nun einen neuen Branch anlege oder ob ich einfach eine Kopie meines Porjektverzechnisses mache ist da nicht wirklich der grossse Unterschied.
Gruss
Claus
Kommentar
-
Zitat von Thallius Beitrag anzeigenWenn er wirklich nur als Einzelkämpfer unterwegs ist, dann macht GIt auch nicht wirklich Sinn. Ob ich nun einen neuen Branch anlege oder ob ich einfach eine Kopie meines Porjektverzechnisses mache ist da nicht wirklich der grossse Unterschied.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
Kommentar
-
Zitat von lottikarotti Beitrag anzeigenGit ist nicht zu vergleichen mit einer einfachen "Kopie meines Projektverzeichnisses". Ich habe ziemlich oft den Fall, dass ich gerade an einem neuen Feature (eigener Branch) arbeite und plötzlich kurzfristig einen Fehler beheben muss. Dann checke ich einfach den letzten stable-Branch aus, korrigiere den Fehler und fahre ein Update aufs Produktivsystem (simple Darstellung). Danach checke ich wieder meinen feature-Branch aus, merge dort den Hotfix rein und arbeite entspannt weiter. Ich habe auch öfter den Fall dass ich Features zurückstellen muss, weil kurzfristig andere Features höher priorisiert werden. Da liegen dann Features so lange in eigenen Branches herum bis sie irgendwann fertig entwickelt werden und in den master-Branch einfließen können. Auch ist Git unheimlich hilfreich wenn man gerne auf mehreren System gleichzeitig an einem Projekt arbeitet; ich nutze bspw. meine Workstation & unterwegs mein MacBook. Dass der stetige Zugriff auf alle älteren Commits auch seine Vorteile hat, brauche ich wohl nicht zu erwähnen
Gerade dein erstes Beispiel ist mit einer Projektkopie genauso einfach machbar. Man macht den fix in der Kopie des letzten Releases und kopiert danach den oder die geänderten sourcen ins aktuelle working Directory. Wie oft kommt es denn bei dir vor, dass bei einem merge tatsächlich die gleichen Dateien betroffen sind? Und wenn, wie oft klappt dann der merge noch? Also bei mir eigentlich nie. Kann aber auch daran liegen dass meine sourcen immer sehr kurz sind.
Den zweiten Fall brauche ich auch nicht. Ich habe nur ein MacBookPro auf dem ich unterwegs und zu Hause arbeite. Zu Hause kommt halt das TB Display und das Magic Keyboard mit Mouse dran und ich habe eine Workstation. Da habe ich immer alles auf einem device.
Und hier kommt der eigentliche Einsatz von GIt bei mir. Außer der obligatorischen TimeMaschine möchte ich natürlich meine Sourcen auch noch irgendwo dezentral auslagern für den Fall das z.B. Mal eingebochen wird und ich gerade meinen Laptop nicht dabei habe oder es brennt oder oder oder...
deshalb nutze ich GIt um meine Sourcen über einen GitHook verschlüsselt auf ein HiDrive zu sichern.
Gruss
ClausPre-Coffee-Posts sind mit Vorsicht zu geniessen!
Kommentar
-
Zitat von Thallius Beitrag anzeigenGerade dein erstes Beispiel ist mit einer Projektkopie genauso einfach machbar. Man macht den fix in der Kopie des letzten Releases und kopiert danach den oder die geänderten sourcen ins aktuelle working Directory.
Zitat von Thallius Beitrag anzeigenWie oft kommt es denn bei dir vor, dass bei einem merge tatsächlich die gleichen Dateien betroffen sind? Und wenn, wie oft klappt dann der merge noch? Also bei mir eigentlich nie. Kann aber auch daran liegen dass meine sourcen immer sehr kurz sind.
Es gibt für mich persönlich faktisch keinen Grund git nicht zu verwenden, denn der operative Overhead ist so dermaßen minimal, dass er selbst bei den kleinsten Projekt zu vernachlässigen ist - dafür sind mir die Vorteile einfach zu wichtig.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
Kommentar
-
Gast
Es gehört sicher nicht zur Tagesordnung, aber es kommt tatsächlich häufig vor.
Kommentar
-
Zitat von xm22 Beitrag anzeigenWas wohl an PHPStorm liegen muss? ^^
Ich bin da empfindlich. Wenn ein Tool nicht zuverlässig läuft und das nicht zeitnah gefixt wird, wechsel ich. Da gibt es selten eine zweite Chance..
Zitat von xm22 Beitrag anzeigenNur aus Neugier, weil das ja mittlerweile die meisten benutzen - Warum nicht?
GIT ist für mich zu eingeschränkt. Wir verwenden ein eigenes System zu Versionierung, dass auch Datenbank-Trunks sauber abbilden, und Datenbank-Strukturen, die Teile von Modulen sind, mergen und upgraden kann.
Das stellt einen Grundbaustein des Core-Systemes dar.
Zitat von xm22 Beitrag anzeigenHeißt, Du arbeitest grundsätzlich allein an Projekten?
Wenn man als Teil eines Teams an einem Projekt arbeitet, dann gehören Guidelines einfach mit dazu um langfristig die Wartbarkeit nicht zu gefährden. Darunter fallen dann auch gemeinsame Code-Reviews. Das verursacht im ersten Moment zwar mehr Aufwand, zahlt sich langfristig aber aus (für das Projekt).
Ich betrachte es mal als Missverständnis aufgrund fehlender Informationen.
Natürlich sprechen wir intern ganz genau über Code-Stil, Techniken, Best-Practices usw. Wir schauen uns die Arbeiten der anderen auch an. Gerade junge Entwickler werden gut und umfangreich geschult,
und zur Selbständigkeit erzogen. Wir brauchen dazu aber keine ständigen Standup-Meetings und Code-Reviews in Gruppen. Es gibt dafür einfach Verantwortliche, ähnlich wie Mentoren und Kollegen, die man im Zweifelsfall in allen Lebenslagen konsultieren kann.
Wir arbeiten sehr stark auf Microservices und kleine Projekte fokusiert. Große Projekte werden so lange aufgeteilt, bis die Einzelteile so klein sind, dass wir dem Kunden schnellstmöglich Tests bereitstellen können.
Das größte Problem ist, wenn man es mal überdenkt, dass ein Kunde nie genau weiß, was er eigentlich möchte. So können wir sehr schnell auf Änderungen in den Anforderungen reagieren.
Das hat starke Ähnlichkeit mit Continuous Integration..
Was wir nicht machen - wir zwingen niemanden:
-alles konfigurierbar zu machen,
-Factories und ähnliche Konstrukte zu verwenden
-den einen vorgeschriebenen Weg zu wählen, weil es so geschrieben steht.
-mit anderen zu reden, indem man ihnen stehend Rede und Antwort steht.
Ich, und einige andere hier, haben da so ihre Erfahrungen gemacht. Scrum funktioniert nur selten - und wird sonst gern falsch umgesetzt, das böse M Wort habe ich mal gestrichen.
Wir haben hier einige sehr clevere Köpfe, die aber zum Teil auch sehr sensibel sind und ihre Macken haben. Die würden auch gar nicht in Concurrency-Orientierte Teams passen.
Dafür arbeiten sie mit dieser Freiheit sehr effektiv.
Diesen Ansatz finde ich kurzsichtig, grob fahrlässig und gewissermaßen egoistisch, denn wenn dieser Entwickler irgendwann das Unternehmen / Projekt verlässt, dürfen sich die anderen mit seinem u.U. exotischen Codestyle herumschlagen.
Das hat überhaupt nichts mit Scrum zu tun. Das setzt der gesunde Menschenverstand voraus.
Kommentar
-
Zitat von faiwel Beitrag anzeigenGIT ist für mich zu eingeschränkt. Wir verwenden ein eigenes System zu Versionierung, dass auch Datenbank-Trunks sauber abbilden, und Datenbank-Strukturen, die Teile von Modulen sind, mergen und upgraden kann.
Das stellt einen Grundbaustein des Core-Systemes dar.
Btw.
Als Dateivergleichs-Programm kann ich Beyond Compare als Ergänzung sehr empfehlen.
Super Programm, hat mir schon oft geholfen.
[COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
[URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]
Kommentar
-
Hallo zusammen,
bei einem neuen Projekt setze ich meist zunächst eine Virtuelle Maschine mittels Ansible auf und installiere mir den Stack, den ich für das Projekt benötige. Darüber hinaus ist die Arbeit mit Git für mich unerlässlich, selbst wenn ich nur alleine an einem Projekt arbeite. Für das Dependency Management kommt der composer hinzu. Bei der IDE bin ich auf PHPStorm festgelegt, da ich bisher nichts vergleichbares kennen gelernt habe. Alles weitere ist dann sehr projektspezifisch. Die Frage ob, und wenn ja, welches Framework eingesetzt wird zum Beispiel. Derzeit arbeite ich meist mit Zend Framework, Zend Expressive oder nutze tatsächlich gar kein Framework, sondern programmiere "zu Fuß".
Was die Datenbankmigrationen angeht, habe ich in letzter Zeit phinx genutzt. Für die Automatisierung von Tasks verwende ich Robo.
Kommentar
-
Ich benutze auch wenn ich alleine an Projekten arbeite gerne Git, weil man damit einfach viel mehr machen kann als mit stumpfen Projekt-Backups. Gerade bei JavaScript Slider und Effekten und so nen Kram kommt es öfter vor, dass ich plötzlich wieder Code aus der Vergangenheit brauche, den ich schon vor 10 Commits komplett entfernt hatte. Auch das könnte man vielleicht noch über die IDE Datei Historie wiederherstellen, diese ist aber meist recht bescheiden im Funktionsumfang und kann nicht mit einer vollwertigen Versionsverwaltung mithalten (außer phpstorm ).
Auch ist Git praktisch, wenn der Kunde mehrere Features gleichzeitig wünscht, dann kann man das schön in Branches aufteilen und / oder an Entwicklungsbranches in Ruhe und isoliert arbeiten, solange es bis es produktionsreife hat und gemergt werden kann.
Und das gleichzeitige Bearbeiten einer Datei kommt schon häufig vor: Denkt nur an Szenarien, wo Software in Release Zyklen veröffentlicht wird. Meistens beziehen sich die Tickets, die in das Release noch mit hinein müssen auf ähnliche Dinge, was dazu führt, dass zwei oder mehr Entwickler gleichzeitig dieselbe Datei bearbeiten.
Oder wenn es eine firmenweite Software gibt, an der auch mehrere Leute arbeiten. Dort kommt es auch häufig zu Dateikonflikten, weil sich unterschiedliche Abteilungen unterschiedliche Dinge wünsche, die aber dieselben Dateien betreffen.
Oder auch bei openSource Projekten, wo es teilweise über 100 Pull Requests gibt, da gibt es sicherlich auch Überschneidungen.
Kommentar
-
Zitat von henrikthesing Beitrag anzeigenWas die Datenbankmigrationen angeht, habe ich in letzter Zeit phinx genutzt.
Kommentar
-
Zitat von derwunner Beitrag anzeigen
Warum nicht Doctrine bzw. genauer gesagt Doctrine Migrations? Die legt Dir sogar Doctrine automatisch an, wenn Du willst, musst dafür nur deine Annotations in den Entity Klassen ändern[URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]
Kommentar
-
Zitat von ChristianK Beitrag anzeigenEs gibt viele gute Gründe, die gegen Doctrine (bzw. ORM) und für Active/Passive Record sprechen. Genauso, wie es viele Gründe gibt, die dafür sprechen.
Und ja, ich bin eigentlich auch eher ein Fan vom Active Record Pattern. Wenn Du das verwenden willst, dann nimm doch einfach nur Doctrine's DBAL. Damit hast Du immer noch automatisch generierte Migrations, wenn Du das Schema Tool nutzt.
Kommentar
Kommentar