Modification sur github.com, branche local n'est plus à jour

Comment push si la branche local n'est plus à jour ?

• git
• git push

• Précédente
• 1
• 2

• unidan, vendredi 21 septembre 2018 à 22h1721/09/18 à 22h17
• Modifié

Tu peux ne pas voir les commits de merge avec --no-merges.

Sinon on est d’accord que merger master dans une branche c’est généralement pas très beau. Dans ton cas, tu sais que si il y a une régression, c’est à cause des commits de master mergés. Si tu le fais dans l’autre sens tu sais que c’est la branche qui a fait la régression et c’est super important d’avoir le commit de merge dans ce cas-là. Mais tu peux être amené à le faire si tu ne veux pas faire des branches à rebaser.

Mais je parlais en particulier des rebase, pas des merge.

• 21/09/18 à 22h17
• Modifié

+0 -0

• anonyme, vendredi 21 septembre 2018 à 22h5521/09/18 à 22h55

Toutes les réponses que j’ai compris sont en verte.

• 21/09/18 à 22h55

+0 -0

• anonyme, lundi 01 octobre 2018 à 23h0501/10/18 à 23h05

J’ai fais un alias dans .bash_aliases :

parse_git_branch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'
}

function zds_rebase {
    git fetch upstream
    git rebase upstream/dev
    git push origin $(parse_git_branch) -f
}

• 01/10/18 à 23h05

+0 -0

• entwanne, lundi 01 octobre 2018 à 23h1201/10/18 à 23h12

Un peu dangereux pour une commande de rebase de faire un push dans la foulée, non ? (surtout avec le -f).

• 01/10/18 à 23h12

entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d’un code pythonique

+2 -0

• anonyme, lundi 01 octobre 2018 à 23h1401/10/18 à 23h14

ah ? Je peux avoir une erreur qui nécessite mon interaction ?

• 01/10/18 à 23h14

+0 -0

• adri1, lundi 01 octobre 2018 à 23h2801/10/18 à 23h28
• Modifié

Non, c’est juste que ta commande fait une manipulation qui entraine une perte de données et peut introduire des erreurs. Forcer sa publication dans la foulée, c’est un peu comme si tu avais des documents auxquels tu tiens, que tu les mélanges avec d’autres documents sans contrôler que t’as rien foutu en l’air, puis que tu allais directement écraser le backup que tu as de l’état précédent. C’est aussi un peu comme si tu jouais à la roulette russe, mais tout seul.

• 01/10/18 à 23h28
• Modifié

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

• entwanne, lundi 01 octobre 2018 à 23h3701/10/18 à 23h37

Et oui, c’est sans compter que le rebase a des chances non nulles d’échouer sur un conflit, et de te demander de le résoudre.

• 01/10/18 à 23h37

entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d’un code pythonique

+0 -0

• anonyme, lundi 01 octobre 2018 à 23h4901/10/18 à 23h49
• Modifié

parse_git_branch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'
}

function zds_rebase {
    git fetch upstream
    git rebase upstream/dev
    echo "Appuyer sur \`y\` pour confirmer et PUSH la modification..."
    read -n 1
    echo ""
    if [ "$REPLY" = "y" ]; then
        git push origin $(parse_git_branch) -f
    else
        echo "Annulé."
    fi
}

Voila ! La commande est censée être parfaite maintenant.

• 01/10/18 à 23h49
• Modifié

+0 -0

• anonyme, lundi 12 novembre 2018 à 21h5012/11/18 à 21h50

La case Allow edits from maintainers est elle utile ? Permet-elle au maintainer de rebase ?

• 12/11/18 à 21h50

+0 -0

• Précédente
• 1
• 2