Ankündigung

Einklappen
Keine Ankündigung bisher.

Start Setup eines neuen PHP Projektes

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Zitat von faiwel Beitrag anzeigen
    Git kommt mir auch nicht ins Haus.
    Spätestens hier würde mich die Begründung sehr interessieren.

    Kommentar


    • #17
      Zitat von ChromOxid Beitrag anzeigen
      Spätestens hier würde mich die Begründung sehr interessieren.
      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
      Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

      Kommentar


      • #18
        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
        Ich finde auch alleine Git schon äußerst hilfreich und es ist schon ein bisschen fähiger als eine simple Kopie.

        Kommentar


        • #19
          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.
          Git 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
          [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

          Kommentar


          • #20
            Zitat von lottikarotti Beitrag anzeigen
            Git 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
            Bevor jetzt wieder irgendwelche Gerüchte aufkommen. Ich nutze selber Git aber ich brauche es wirklich eigentlich so gut wie nie für solche Aktionen.
            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

            Claus
            Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

            Kommentar


            • #21
              Zitat von Thallius Beitrag anzeigen
              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.
              Ich habe hier ein Projekt das aktuell 37 Feature-Branches hat, 4 unterschiedliche Release-Branches, 9 Branches mit Modulen die nicht mehr im Release vorhanden sind aber jederzeit reaktiviert werden können (quasi Sicherungskopien). Dazu kommen dann noch Branches für die Testphasen und so'n Kram wie der obligatorische "develop"-Branch. Manuell Ordner kopieren und Änderungen zusammenführen? Good luck.

              Zitat von Thallius Beitrag anzeigen
              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.
              Es gehört sicher nicht zur Tagesordnung, aber es kommt tatsächlich häufig vor. In 90% der Fälle (meine persönliche Erfahrung) führt git den Code ohne Probleme automatisch zusammen ("git merge blubb"), bei einem Aufwand von 2 Sekunden. Wenn es doch mal Konflikte gibt, werden die betroffenen Dateien aufgelistet und ich kann die Probleme manuell beheben, was meistens nicht mehr als 5 Minuten in Anspruch nimmt. Sich darauf zu verlassen dass Fehler immer nur dort auftreten wo ich gerade keine Änderungen vorgenommen habe, ist mir zu riskant. Und letztlich habe ich nur einen Produktivitätsverlust, wenn ich alles manuell mache.

              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


              • #22
                Es gehört sicher nicht zur Tagesordnung, aber es kommt tatsächlich häufig vor.
                Spätestens, wenn man mit mehr als einer Person an einem Projekt arbeitet.

                Kommentar


                • #23
                  Zitat von xm22 Beitrag anzeigen
                  Was wohl an PHPStorm liegen muss? ^^
                  Ist schon ein Weilchen her. Mit dem Fehler war ich allerdings nicht allein..
                  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 anzeigen
                  Nur aus Neugier, weil das ja mittlerweile die meisten benutzen - Warum nicht?
                  (Hier ging es um GIT.)

                  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 anzeigen
                  Heißt, Du arbeitest grundsätzlich allein an Projekten?
                  Nein, wir arbeiten hier im Team. Aber jeder ist für seinen Teil zuständig, und für das, was er am besten kann.




                  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 bin nicht näher darauf eingegangen, aber ich habe schon damit gerechnet, dass dieser Einwand kommt.
                  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.
                  Exotische Code-Stile werden hier allgemein nicht gern gesehen. Leute, die elitär schreiben, und denken sie seien besonders clever, weil sie ihre Codes schön verschlüsseln haben es nie leicht. Meist steckt da auch ein Problem dahinter, über das man dann mal sprechen muss. Wenn Du Deinen Code nach 3 Wochen selbst nicht mehr verstehst, musst Du damit rechnen, dass man dich nicht mehr ernst nimmt.

                  Das hat überhaupt nichts mit Scrum zu tun. Das setzt der gesunde Menschenverstand voraus.

                  Kommentar


                  • #24
                    Zitat von faiwel Beitrag anzeigen
                    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.
                    Wuh. Zwischen den Aussagen "Git kommt mir nicht ins Haus" und "Wir nutzen ein eigenes System [...]" liegen schon Welten. :>

                    Btw.
                    Als Dateivergleichs-Programm kann ich Beyond Compare als Ergänzung sehr empfehlen.
                    100 mal Thumbs Up.
                    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


                    • #25
                      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


                      • #26
                        Kurz und Bündig mein Setup für Projekte:

                        - LAMP
                        - SVN
                        - Eclipse
                        - Composer

                        Kommentar


                        • #27
                          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


                          • #28
                            Zitat von henrikthesing Beitrag anzeigen
                            Was die Datenbankmigrationen angeht, habe ich in letzter Zeit phinx genutzt.
                            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

                            Kommentar


                            • #29
                              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
                              Es 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.
                              [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


                              • #30
                                Zitat von ChristianK Beitrag anzeigen
                                Es 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.
                                Aha. Habe bisher keinen einzigen (guten) Grund gehört. Und die Hauptbehauptung, dass ein Framework die Gesamtsoftware langsamer machen würde, stimmt so auch nicht. Im Gegenteil, mit Doctrine laufen viele Queries viel schneller ab, weil das eine Caching Ebene enthält.
                                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

                                Lädt...
                                X