Entwicklungszweig mit Master zusammenführen

Ich habe nämlich zwei Zweige masterund developmentin einem GitHub Repository. Ich mache meine gesamte Entwicklung in der Entwicklungsbranche wie gezeigt.

git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development

Jetzt möchte ich alle Änderungen am developmentZweig in den zusammenführen master. Mein aktueller Ansatz ist:

git checkout master 
git merge development
git push -u origin master 

Bitte lassen Sie mich wissen, ob das von mir befolgte Verfahren korrekt ist.

Im Allgemeinen verschmelze ich gerne mit masterder developmentersten, damit ich bei Konflikten die Lösung in der developmentFiliale selbst lösen kann und meine masterÜberreste sauber bleiben.

(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won't be any conflicts now)

Es gibt keinen großen Unterschied zwischen den beiden Ansätzen, aber ich habe manchmal bemerkt, dass ich den Zweig masternach dem Zusammenführen noch nicht zusammenführen möchte oder dass noch mehr Arbeit zu tun ist, bevor diese zusammengeführt werden können , also neige ich dazu, masterbis zum letzten Zeug unberührt zu bleiben.

EDIT: Aus Kommentaren

Wenn Sie verfolgen möchten, wer wann die Zusammenführung durchgeführt hat, können Sie --no-ffbeim Zusammenführen das Flag verwenden, um dies zu tun. Dies ist im Allgemeinen nur nützlich beim Einarbeiten developmentin die master(letzte Stufe), da müssen Sie möglicherweise verschmelzen masterin development(ersten Schritt) mehrfach in Ihrem Workflow und das Erstellen von einem Commit - Knoten für diese nicht sehr nützlich sein könnte.

git merge --no-ff development

Persönlich ähnelt mein Ansatz Ihrem, mit ein paar weiteren Zweigen und einigen Quetschungen von Commits, wenn sie zum Master zurückkehren.

Einer meiner Mitarbeiter mag es nicht so sehr, die Filialen wechseln zu müssen, und bleibt in der Entwicklungsbranche mit etwas Ähnlichem wie den folgenden, die alle aus der Entwicklungsbranche ausgeführt werden.

git fetch origin master

git merge master

git push origin development:master

In der ersten Zeile wird sichergestellt, dass er über alle Upstream-Commits verfügt, die seit der letzten Aktualisierung seines lokalen Repositorys erstellt wurden.

Die zweite zieht diese Änderungen (falls vorhanden) vom Master in die Entwicklung

Der dritte schiebt den Entwicklungszweig (der jetzt vollständig mit dem Master zusammengeführt ist) auf Ursprung / Master.

Ich mag seinen grundlegenden Workflow ein wenig falsch haben, aber das ist das Wesentliche.

Erklärung von unten für diejenigen, die ohne Kenntnis der Zweige hierher gekommen sind.

Grundlegende Logik für die Entwicklung von Master-Zweigen lautet: Sie arbeiten nur an anderen Zweigen und verwenden Master nur zum Zusammenführen anderer Zweige.

Sie beginnen auf diese Weise, einen neuen Zweig zu erstellen:

1) Klonen Sie das Repository in Ihrem lokalen Verzeichnis (oder erstellen Sie ein neues Repository):

$ cd /var/www
$ git clone git@bitbucket.org:user_name/repository_name.git

2) Erstellen Sie einen neuen Zweig. Es enthält die neuesten Dateien Ihres Hauptzweig-Repositorys

$ git branch new_branch

3) Ändern Sie Ihren aktuellen Git-Zweig in new_branch

$ git checkout new_branch

4) Codieren, Festschreiben wie gewohnt…

$ git add .
$ git commit -m “Initial commit”
$ git push (pushes commits only to “new_branch”)

5) Wenn der Job in diesem Zweig beendet ist, führen Sie ihn mit dem Zweig "Master" zusammen:

$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldn’t have any  commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all “new_branch” commits to both branches - “master” and “new_branch”)

Update: Ich empfehle dringend, GitKraken zu verwenden, um den visuellen Baum der Änderungen zu sehen und alle Logik und Commits besser zu sehen.

Es wäre großartig, wenn Sie den Git Flow-Workflow verwenden könnten . Es kann Entwicklungszweig leicht in Master zusammenführen.

Befolgen Sie einfach die hier genannten Anweisungen zum Git-Flow:

SCHRITTE:

• Richten Sie das Git-Flow-Projekt ein
• Erstellen Sie Zweige und führen Sie alles zusammen, um sich zu entwickeln
• Führen Sie den Befehl aus git flow release start <version_number>
• Geben Sie dann eine aussagekräftige Nachricht für die Veröffentlichung an
• Führen Sie den Befehl aus git flow release finish <version_number>
• es wird alles in fusionieren Master und den Zweig ändern Master .
• Führen Sie den Befehl aus git push, um die Änderungen auf dem Remote- Master zu veröffentlichen .

Weitere Informationen finden Sie auf der Seite - http://danielkummer.github.io/git-flow-cheatsheet/

1. //pull the latest changes of current development branch if any        
git pull (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any
git pull

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Ja, das ist richtig, aber es sieht nach einem sehr einfachen Workflow aus, bei dem Sie Änderungen nur puffern, bevor sie für die Integration bereit sind. Sie sollten sich erweiterte Workflows ansehen , die Git unterstützt. Vielleicht gefällt Ihnen der Themenzweig- Ansatz, mit dem Sie mehrere Features gleichzeitig bearbeiten können, oder der Abschluss-Ansatz, mit dem Sie Ihren aktuellen Workflow ein wenig erweitern können.

Wenn Sie einen Mac oder Ubuntu verwenden, wechseln Sie in den Arbeitsordner des Zweigs. Im Terminal

Angenommen, Harisdev ist der Filialname.

git checkout master

Wenn nicht verfolgte oder nicht festgeschriebene Dateien vorhanden sind, wird eine Fehlermeldung angezeigt, und Sie müssen alle nicht verfolgten oder nicht festgeschriebenen Dateien festschreiben oder löschen.

git merge harisdev 

git push origin master

Ein letzter Befehl zum Löschen des Zweigs.

$ git branch -d harisdev

Schritt 1

Erstellen und wechseln Sie zu einem neuen "dev" -Zweig, in dem Ihre lokalen Git-Dateien mit der Remote synchronisiert sind, der "dev" -Zweig jedoch noch nicht vorhanden ist.

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch's files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.

Schritt 2

Nehmen Sie Ihre Änderungen am Zweig "dev" vor (Ihren aktuellen, wenn Sie Schritt 1 ausführen), schreiben Sie sie fest und übertragen Sie sie in den Remote-Zweig "dev".

git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.

Schritt 3

Füge deinen "dev" -Zweig in den "master" ein.

git checkout dev # switch to "dev" branch if you're not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn't have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.

So mache ich es normalerweise. Stellen Sie zunächst sicher, dass Sie bereit sind, Ihre Änderungen in master zusammenzuführen.

1. Überprüfen Sie, ob die Entwicklung mit den neuesten Änderungen von Ihrem Remote-Server auf dem neuesten Stand ist git fetch
2. Sobald der Abruf abgeschlossen ist git checkout master.
3. Stellen Sie durch Ausführen sicher, dass der Hauptzweig über die neuesten Updates verfügt git pull
4. Sobald die Vorbereitungen abgeschlossen sind, können Sie mit dem Zusammenführen beginnen git merge development
5. Schieben Sie die Änderungen mit git push -u origin masterund Sie sind fertig.

Weitere Informationen zum Zusammenführen von Git finden Sie im Artikel.

1) Überprüfen Sie bei der Zweigstellenentwicklung den Git-Status mit dem folgenden Befehl:

git status

Es sollte keinen nicht festgeschriebenen Code geben. Wenn dies der Fall ist, geben Sie Ihren Code in den Entwicklungszweig ein:

git add *

git commit -m "My initial commit message"

git push origin Development

2) Führen Sie im Entwicklungszweig die folgenden zwei Befehle aus:

git branch -f master HEAD

git push -f origin master

Es wird Ihren Entwicklungszweigcode an den Hauptzweig weiterleiten.

Basierend auf @Sailesh und @DavidCulp:

(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won't be any conflicts now)

Der erste Befehl stellt sicher, dass alle Upstream-Commits an den Remote-Master gesendet wurden, wobei die Sailesh-Antwort nicht erfolgen würde.

Der zweite führt eine Zusammenführung durch und erstellt Konflikte, die Sie dann lösen können.

Danach können Sie den Master endgültig auschecken, um zum Master zu wechseln.

Anschließend führen Sie den Entwicklungszweig mit dem lokalen Master zusammen. Das No-ff-Flag erstellt einen Commit-Knoten im Master, damit die gesamte Zusammenführung verfolgt werden kann.

Danach können Sie Ihre Zusammenführung festschreiben und vorantreiben.

Durch dieses Verfahren wird sichergestellt, dass ein Zusammenführungs-Commit von der Entwicklung zum Master vorhanden ist, das die Benutzer sehen können. Wenn sie sich dann den Entwicklungszweig ansehen, können sie die einzelnen Commits sehen, die Sie während der Entwicklung für diesen Zweig vorgenommen haben.

Optional können Sie Ihr Merge-Commit ändern, bevor Sie es verschieben, wenn Sie eine Zusammenfassung der Vorgänge im Entwicklungszweig hinzufügen möchten.

BEARBEITEN: Meine ursprüngliche Antwort schlug eine vor, git merge masterdie nichts tat, es ist besser, git merge FETCH_HEADnach dem Abrufen des Ursprungs / Masters zu tun

Sobald Sie den Entwicklungszweig "ausgecheckt" haben, ...

 git add .
 git commit -m "first commit"
 git push origin dev
 git merge master

 git checkout master 
 git merge dev
 git push origin master 

Wenn Sie Gerrit verwenden, funktionieren die folgenden Befehle einwandfrei.

git checkout master
git merge --no-ff development

Sie können mit der Standard-Commit-Nachricht speichern. Stellen Sie sicher, dass die Änderungs-ID generiert wurde. Sie können den folgenden Befehl verwenden, um sicherzustellen.

git commit --amend

Drücken Sie dann mit dem folgenden Befehl.

git push origin HEAD:refs/for/refs/heads/master

Möglicherweise wird eine Fehlermeldung wie die folgende angezeigt.

! [remote rejected] HEAD -> refs/for/refs/heads/master (you are not allowed to upload merges)

Um dies zu beheben, muss der Gerrit-Projektadministrator eine weitere Referenz in Gerrit mit dem Namen "refs / for / refs / Heads / master" oder "refs / for / refs / Heads / *" erstellen (die in Zukunft alle Zweige abdeckt). Erteilen Sie dieser Referenz dann die Berechtigung "Push Merge Commit" und bei Bedarf die Berechtigung "Senden", um die GCR zu senden.

Versuchen Sie nun den obigen Push-Befehl erneut, und es sollte funktionieren.

Credits:

https://github.com/ReviewAssistant/reviewassistant/wiki/Merging-branches-in-Gerrit

https://stackoverflow.com/a/21199818/3877642

Ich denke, die einfachste Lösung wäre

git checkout master
git remote update
git merge origin/Develop -X theirs
git commit -m commit -m "New release"
git push --recurse-submodules=check --progress "origin" refs/heads/Master

Dadurch bleibt auch die Geschichte aller verwendeten Zweige erhalten

1. //push the latest changes of current development branch if any        
git push (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any from (current development branch)
git pull origin (current development branch)

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Error
To https://github.com/rajputankit22/todos-posts.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/rajputankit22/todos-posts.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Then Use 
5. //push the master branch forcefully
git push -f origin master