Fusionner la branche de développement avec le maître

J'ai deux branches à savoir masteret developmentdans un référentiel GitHub. Je fais tout mon développement dans la branche développement comme indiqué.

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

Maintenant, je veux fusionner toutes les modifications de la developmentbranche dans le master. Mon approche actuelle est:

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

Veuillez me faire savoir si la procédure que je suis est correcte.

J'aime généralement fusionner masterdans le developmentpremier afin que s'il y a des conflits, je puisse résoudre dans la developmentbranche elle-même et mes masterrestes propres.

(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)

Il n'y a pas beaucoup de différence entre les deux approches, mais j'ai parfois remarqué que je ne veux pas encore fusionner la branche master, après les avoir fusionnées, ou qu'il reste encore du travail à faire avant de pouvoir les fusionner , donc j'ai tendance à laisser masterintacte jusqu'à la fin.

EDIT: Des commentaires

Si vous souhaitez savoir qui a effectué la fusion et quand, vous pouvez utiliser l' --no-ffindicateur lors de la fusion pour le faire. Ceci est généralement utile que lors de la fusion developmentdans la master(dernière étape), parce que vous pourriez avoir besoin de fusionner masteren development(première étape) plusieurs fois dans votre flux de travail et la création d' un noeud pour commettras ceux - ci pourraient ne pas être très utile.

git merge --no-ff development

Personnellement, mon approche est similaire à la vôtre, avec quelques branches de plus et quelques écrasements de commits quand ils reviennent au master.

Un de mes collègues n'aime pas trop devoir changer de branche et reste sur la branche de développement avec quelque chose de similaire aux suivants tous exécutés à partir de la branche de développement.

git fetch origin master

git merge master

git push origin development:master

La première ligne s'assure qu'il a des validations en amont qui ont été faites pour master depuis la dernière mise à jour de son référentiel local.

Le second tire ces changements (le cas échéant) du maître au développement

Le troisième pousse la branche de développement (maintenant complètement fusionnée avec master) vers origin / master.

J'ai peut-être un peu tort son flux de travail de base, mais c'est l'essentiel.

Explication du bas pour ceux qui sont venus ici sans aucune connaissance des branches.

La logique de développement de branche principale de base est la suivante: vous ne travaillez que sur une autre branche et utilisez le maître uniquement pour fusionner une autre branche.

Vous commencez à créer une nouvelle branche de cette façon:

1) Cloner le référentiel dans votre répertoire local (ou créer un nouveau référentiel):

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

2) Créez une nouvelle branche. Il contiendra les derniers fichiers de votre référentiel de branche principale

$ git branch new_branch

3) Changez votre branche git actuelle en new_branch

$ git checkout new_branch

4) Faites du codage, engage, comme d'habitude…

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

5) Lorsque le travail est terminé sur cette branche, fusionnez avec la branche «maître»:

$ 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”)

Mise à jour: je recommande fortement d'utiliser GitKraken pour cela pour voir l'arborescence visuelle des changements et mieux voir toute la logique et les validations.

Ce serait formidable si vous pouviez utiliser le workflow Git Flow . Il peut fusionner facilement la branche de développement en maître.

Ce que vous voulez faire, c'est simplement suivre l'instruction git-flow mentionnée ici:

PAS:

• configurer le projet git-flow
• créer des succursales et tout fusionner pour se développer
• exécutez la commande git flow release start <version_number>
• puis fournir un message significatif pour la sortie
• exécutez la commande git flow release finish <version_number>
• il fusionnera tout en maître et changera la branche en maître .
• exécutez la commande git pushpour publier les modifications sur le maître distant .

Pour plus d'informations, visitez la page - 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

Oui, c'est correct, mais cela ressemble à un flux de travail très basique, où vous mettez simplement les modifications en mémoire tampon avant qu'elles ne soient prêtes pour l'intégration. Vous devriez examiner des workflows plus avancés pris en charge par git. Vous aimerez peut-être l' approche par branche de sujet , qui vous permet de travailler sur plusieurs fonctionnalités en parallèle, ou l' approche de graduation qui étend un peu votre flux de travail actuel.

Si vous êtes sur Mac ou Ubuntu, accédez au dossier de travail de la branche. Dans le terminal

supposons que harisdev est le nom de la branche.

git checkout master

s'il y a des fichiers non suivis ou non validés, vous obtiendrez une erreur et vous devrez valider ou supprimer tous les fichiers non suivis ou non validés.

git merge harisdev 

git push origin master

Une dernière commande pour supprimer la branche.

$ git branch -d harisdev

Étape 1

Créez et passez à une nouvelle branche "dev", où vos fichiers git locaux sont synchronisés avec la branche distante mais "dev" n'existe pas encore.

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.

Étape 2

Apportez vos modifications à la branche "dev" (votre courant si vous suivez l'étape 1), validez-les et envoyez-les à la branche "dev" distante.

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.

Étape 3

Fusionnez votre branche "dev" dans le "master".

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.

C'est comme ça que je le fais d'habitude. Tout d'abord, assurez-vous que vous êtes prêt à fusionner vos modifications dans master.

1. Vérifiez si le développement est à jour avec les dernières modifications de votre serveur distant avec un git fetch
2. Une fois la récupération terminée git checkout master.
3. Assurez-vous que la branche principale dispose des dernières mises à jour en exécutant git pull
4. Une fois les préparatifs terminés, vous pouvez démarrer la fusion avec git merge development
5. Poussez les modifications avec git push -u origin masteret vous avez terminé.

Vous pouvez en savoir plus sur la fusion de git dans l'article.

1) Sur le développement de branche, vérifiez l'état de git en utilisant la commande suivante:

git status

Il ne devrait pas y avoir de code non engagé. Si c'est le cas, poussez votre code sur la branche Développement:

git add *

git commit -m "My initial commit message"

git push origin Development

2) Sur la branche Développement, exécutez les deux commandes suivantes:

git branch -f master HEAD

git push -f origin master

Il poussera votre code de branche de développement vers la branche principale.

Basé sur @Sailesh et @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)

La première commande s'assurera que vous avez tous les commits en amont effectués sur le maître distant, avec une réponse Sailesh qui ne se produirait pas.

Le second effectuera une fusion et créera des conflits que vous pourrez ensuite résoudre.

Après cela, vous pouvez enfin commander master pour passer en master.

Ensuite, vous fusionnez la branche de développement sur le maître local. L'indicateur no-ff créera un nœud de validation dans master pour que toute la fusion soit traçable.

Après cela, vous pouvez valider et pousser votre fusion.

Cette procédure s'assurera qu'il y a un commit de fusion du développement au master que les gens peuvent voir, puis s'ils regardent la branche de développement, ils peuvent voir les validations individuelles que vous avez faites dans cette branche pendant son développement.

Vous pouvez éventuellement modifier votre commit de fusion avant de le pousser, si vous souhaitez ajouter un résumé de ce qui a été fait dans la branche de développement.

EDIT: ma réponse d'origine suggérait un git merge masterqui n'a rien fait, il vaut mieux le faire git merge FETCH_HEADaprès avoir récupéré l'origine / master

Une fois que vous avez «vérifié» la branche de développement, vous ...

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

 git checkout master 
 git merge dev
 git push origin master 

Si vous utilisez gerrit, les commandes suivantes fonctionnent parfaitement.

git checkout master
git merge --no-ff development

Vous pouvez enregistrer avec le message de validation par défaut. Assurez-vous que l'ID de modification a été généré. Vous pouvez utiliser la commande suivante pour vous en assurer.

git commit --amend

Poussez ensuite avec la commande suivante.

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

Vous pourriez rencontrer un message d'erreur comme ci-dessous.

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

Pour résoudre ce problème, l'administrateur du projet gerrit doit créer une autre référence dans gerrit nommée 'refs / for / refs / heads / master' ou 'refs / for / refs / heads / *' (qui couvrira toutes les branches à l'avenir). Accordez ensuite l'autorisation «Push Merge Commit» à cette référence et l'autorisation «Soumettre» si nécessaire pour soumettre le GCR.

Maintenant, essayez à nouveau la commande push ci-dessus, et cela devrait fonctionner.

Crédits:

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

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

Je pense que la solution la plus simple serait

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

Cela préserve également l'historique de toutes les branches utilisées

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