Rebasez votre propre branche de fonctionnalité sur la branche principale pour garder un historique linéaire et résoudre les conflits par petites doses avant la revue. Faites un merge en intégrant cette branche dans une branche partagée, et ne rebasez jamais une branche que d'autres ont déjà récupérée, parce que réécrire un historique partagé force tout le monde à une récupération. En bref : rebasez le travail privé, mergez le travail public, et écrasez quand l'historique des commits n'apporte rien aux futurs lecteurs.
Pourquoi les recruteurs posent cette question
L'usage de Git dit au recruteur comment vous travaillez avec les autres. Il veut la règle historique privé contre partagé, la compréhension que le rebase réécrit les commits au lieu de les déplacer, et du pragmatisme sur les conventions d'équipe. Quelqu'un qui impose une seule stratégie partout, ou qui ne sait pas expliquer pourquoi un force push sur une branche partagée fait des dégâts, a tendance à créer de la friction dans une équipe.
Comment structurer votre réponse
- Énoncez la règle branche privée contre branche partagée.
- Expliquez ce que le rebase fait réellement aux identifiants de commit.
- Dites quand vous écraseriez plutôt.
- Déférez à la convention d'équipe quand il en existe une.
Exemple de réponse
Ma règle, c'est rebaser l'historique privé, merger l'historique partagé. Tant qu'une branche de fonctionnalité est à moi, je la rebase régulièrement sur main, parce que ça garde le diff honnête et que je préfère rencontrer les conflits en trois petites doses plutôt qu'en une énorme à la fin. Quand elle entre dans main, je merge, en général en écrasant, parce que personne qui lira le log dans six mois ne veut de mes commits corrige la faute de frappe. Ce que je ne ferai pas, c'est rebaser une branche que quelqu'un d'autre a récupérée, puisque le rebase ne déplace pas les commits, il en crée de nouveaux avec de nouveaux hachages, et la copie des originaux chez les autres est désormais orpheline. Ça veut dire un force push et quelqu'un qui perd du travail. J'ai dû guider un collègue à travers le reflog pour se remettre exactement de ça. Au-delà de la règle, je suis ce que l'équipe fait déjà, parce qu'un historique cohérent que tout le monde comprend vaut mieux que ma préférence personnelle, et ce n'est pas une colline sur laquelle mourir en revue de code.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Comment récupéreriez-vous un commit perdu après un mauvais rebase ?
- Que vous permet de nettoyer un rebase interactif ?
- Comment gérez-vous une branche de longue durée qui a beaucoup dérivé ?
Autres questions pour Ingénieur logiciel
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions