Merge, lokal oder im remute repro

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Merge, lokal oder im remute repro

    Hallo,
    Wo macht ihr einen merge im lokalen oder externen repro?
    Ich benutze "gitlab.com" dort lassen sich scheinbar auch merges durchführen. Oder ist das nur eine Mitteilung an den Admin das er einen Merge machen soll?
    Habe vor ein zwei User an einen Projekt arbeiten zu lassen. Die User sollen einen eigenen Branch haben ,der ja auch von gitlab selber angelegt wird.
    So nun möchte ich die Änderungen von einen User branch zu dem gemeinsamen develop branch mergen.
    Nun zu meiner eigentlichen Frage.
    Wo mache ich das , gleich im remute repro bei gitlab ,oder im lokalen repro nach dem ich dem User Branche mit pop geupdate habe?
    Ist es überhaupt möglich das alles online bei gitlab zu machen?
    Reicht es nach einem lokalen merge ein push zum repro?
    Wie macht ihr das oder wie macht man es richtig?

    Ps. Zu gitlab ist es dafür besser eine Gruppe bei gitlab zu erstellen? Oder recht ein normales repro mit mehreren usern u branches?
    Welches GUI Tool für Windows nutzt ihr?

    Da fällt mir noch eine Frage ein macht ihr den push, pop in Android Studio oder in einen gui tool oder bash? Was ist sinnvoller?

    Vielle Grüsse Jörg.
    Ein Feedback auf Tipps ist auch schön. :P

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von jogimuc ()

  • Ein merge ist erstmal ein merge, man merged eben branches. Die Frage ist was man tun möchte, möchte man einen merge request erstellen um den gepushten code reviewen zu können, oder will man einfach mergen. Du könntest einfach lokal mergen und das dann pushen wenn dein remote main repository nicht protected ist.

    Sinnvoller ist es aber zu sagen, jeder forkt das remote main repository und macht seine Änderungen auf seinem remote fork. Das heißt du clonest lokal deinen remote fork, machst dann lokal deine änderungen und pushst diese zum remote fork. Dann erstellst du im gitlab einen Merge Request vom jeweiligen branch deines remote forks auf den jeweiligen branch deines remote main repositories. Klingt ein bisschen durcheinander, ist aber von mir wahrscheinlich einfach nur dumm erklärt :P
  • Ben erstmal danke. Werde ich mir nochmal genauer anschauen.
    Frage was ist ein Fork?


    Ob mein Remute repro prodected ist weiß ich nicht muss icht testen. Denke aber mal ja ist ja kostenlos.

    Muss das mal mit einen Test Projekt durchspielen und mir einen zweiten User bei gitlab machen.

    Was ist besser bei gitlab nur ein Projekt für zwei User oder eine Gruppe?
    Ein Feedback auf Tipps ist auch schön. :P

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von jogimuc ()

  • @Ben Ich denke mit Fork meist du das Prinzip.
    Ist das mit GitLab auch möglich?
    Denke dazu brauche ich eine Gruppe bei giLab oder Organization bei gitHub?

    Für zwei oder maximal drei User würde es doch auch reichen wenn jeder einen eigenen Branch nutzt.


    Integration-Manager Workflow
    Weil Git ermöglicht, eine Vielzahl von externen Repositories zu betreiben, ist es außerdem möglich, einen Arbeitsprozess zu gestalten, in dem jeder Entwickler Schreibzugriff auf sein eigenes öffentliches Repository hat, aber nur Lesezugriff auf die Repositories von allen anderen Beteiligten. In diesem Szenario stellt jedes Repository ein eigenes „offizielles“ Projekt dar. Um zu einem solchen distribuierten Projekt Änderungen beizusteuern, kannst Du einen eigenen, öffentlichen Klon des Projektes anlegen und Deine Änderungen dort publizieren. Anschließend kannst Du den Betreiber des Haupt-Repositories bitten, Deine Änderungen in sein Repository zu übernehmen. Er kann dann Dein Repository als ein externes Repository auf seinem Rechner einrichten, Deine Änderungen lokal testen, sie in einen seiner Branches (z.B. master) mergen und dann in sein öffentliches Repository pushen. Dieser Prozess läuft wie folgt ab (siehe Bild 5-2):
    1. Der Projekt Betreiber pusht in ein öffentliches Repository.
    2. Ein Mitarbeiter klont das Repository und nimmt Änderungen daran vor.
    3. Der Mitarbeiter pusht diese in sein eigenes öffentliches Repository.
    4. Der Mitarbeiter schickt dem Betreiber eine E-Mail und bittet darum, die Änderungen zu übernehmen.
    5. Der Betreiber richtet das Repository des Mitarbeiters als ein externes Repository ein und führt die Änderungen mit einem seiner eigenen Branches zusammen.
    6. Der Betreiber pusht die zusammengeführten Änderungen in sein öffentliches Repository.
    [Blockierte Grafik: https://git-scm.com/figures/18333fig0502-tn.png]
    Bild 5-2. Integration-Manager Workflow
    Ein Feedback auf Tipps ist auch schön. :P
  • wenn du in deinem projekt bist gibt es bei gitlab und github einen button zum forken des projekts. Du kopierst das projekt sozusagen nochmal zu deinem user. Google mal nach "gitlab fork".Protected heißt in dem kontext nicht ob kostenlos oder nicht, sondern ob zu dem projekt gepusht werden darf oder nur mittels merge requests änderungen eingespielt werden dürfen.
  • Danke Ben für dir Erleuterung.
    Was du mit Prodectet meintest ist mir schon klar das das nichtsts mit kostenlos oder bezahlen zu tuhen hat. Ich meinte da ich nur einen kostenlosen Account habe könnte es sein das ich nicht die rechte habe. Habe es bis jetzt noch nicht getestet.
    Trostem Dankeschön.
    Im Prinzip ist aber das was ich oben eingefügt habe oder?
    Ist es dazu besser in gitlab eine Gruppe anzulegen oder nur ein Projekt. Bei github ist Gruppe glaube Organisation.
    Ein Feedback auf Tipps ist auch schön. :P