Las 40 preguntas y respuestas principales de la entrevista de GIT en 2021

top 40 git interview questions

Preguntas más populares de la entrevista de GIT con respuestas y ejemplos:

Este tutorial informativo incluye un conjunto de las preguntas más frecuentes en las entrevistas de Git junto con sus respuestas descriptivas. Estas preguntas sin duda lo ayudarán a prepararse y resolver con éxito cualquier entrevista de Git.

Ya sea que sea un novato o un profesional experimentado, estas preguntas de entrevista en Git y respuestas detalladas definitivamente lo ayudarán a enriquecer su conocimiento del tema y sobresalir en su trabajo y en sus entrevistas.

¡¡Empecemos!!

Preguntas más frecuentes de la entrevista de GIT

A continuación se enumeran algunas de las preguntas de entrevistas de GIT más frecuentes para su referencia.

P # 1) ¿Qué es Git?

Responder: Git es una herramienta de control de versiones distribuidas. Es compatible con flujos de trabajo distribuidos no lineales, ya que ofrece seguridad de datos para crear software de buena calidad.

Git es gratuito y de código abierto. Se puede utilizar para casi cualquier tipo de proyecto, ya sea pequeño o grande. Git es conocido por su gran velocidad y eficiencia. Los repositorios de Git son muy fáciles de encontrar y acceder. Debido a sus ciertas características, Git es altamente flexible, seguro y compatible con su sistema.

P # 2) ¿Qué es un sistema de control de versiones distribuido?

Responder: Un VCS distribuido es un sistema que no depende de un servidor central para mantener un archivo de proyecto y todas sus versiones. En VCS distribuido, cada colaborador o desarrollador obtiene una copia local del repositorio principal y esto se denomina clon.

(imagen fuente )

Como puede ver en el diagrama anterior, cada colaborador mantiene un repositorio local en sus máquinas locales. Pueden confirmar y actualizar los repositorios locales sin ningún problema.

Mediante una operación de extracción, un desarrollador puede actualizar su repositorio local con los últimos cambios del servidor central. Mediante la operación de inserción, pueden enviar sus cambios desde el repositorio local al servidor central.

P # 3) ¿Quién creó Git?

Responder: Git fue creado por Linus Torvalds en 2005 en el camino hacia el desarrollo del kernel de Linux.

P # 4) ¿Qué idioma se usa en Git?

Responder: C es el lenguaje de programación subyacente en el que está escrito Git. El lenguaje C hace que Git sea rápido evitando los gastos generales del tiempo de ejecución vinculados con otros lenguajes de programación de alto nivel.

P # 5) ¿Cuáles son las ventajas / características principales de Git?

Respuesta: A continuación se enumeran los diversos f eatures de Git.

(i) Libre y de código abierto:

Git se emite bajo la licencia de código abierto GPL (Licencia pública general). No necesita pagar nada para usar Git.

Es absolutamente gratis. Como es de código abierto, puede modificar el código fuente según sus necesidades.

(ii) Velocidad:

Como no es necesario que se conecte a ninguna red para ejecutar todas las acciones, realiza todas las tareas rápidamente. Obtener el historial de versiones de un repositorio almacenado localmente puede ser cien veces más rápido que obtenerlo del servidor remoto.

Git está escrito en C, que es el lenguaje de programación subyacente que evade los gastos generales del tiempo de ejecución vinculados con otros lenguajes de alto nivel.

(iii) Escalable:

Git es altamente escalable. Entonces, si el número de colaboradores aumenta en el próximo tiempo, entonces Git puede adaptarse fácilmente a este cambio.

A pesar de que Git representa un repositorio completo, los datos guardados en el lado del cliente son muy pequeños, ya que Git compacta la gran cantidad de datos a través de una técnica de compresión sin pérdidas.

(iv) Confiable:

Como cada colaborador tiene su propio repositorio local, en las instancias de una falla del sistema, los datos perdidos se pueden recuperar de cualquiera de los repositorios locales. En todo momento, tendrás una copia de seguridad de todos tus archivos.

(v) Seguro:

Git utiliza SHA1 (función hash segura) para nombrar e identificar objetos dentro de su repositorio. Cada artefacto y confirmación se suma y recupera a través de su suma de verificación durante el pago.

El historial de Git se guarda de una manera en la que el ID de una versión específica (una confirmación en términos de Git) se basa en el historial de desarrollo total que se ejecuta hasta esa confirmación. Una vez que se envía una versión de archivo a Git, no hay forma de cambiarla sin que se note.

(vi) Económico:

En el caso de un sistema de control de versiones centralizado, el servidor central debe ser lo suficientemente fuerte para atender las solicitudes de todo el equipo. Esto no es un problema para los equipos más pequeños, sin embargo, a medida que el equipo se expande, las limitaciones de hardware del servidor pueden ser un impedimento para el rendimiento.

En el caso de los sistemas de control de versiones distribuidos como Git, los miembros del equipo no requieren interacción con el servidor, como se espera cuando se les pide que realicen cambios o realicen cambios. Todo el trabajo pesado ocurre en el extremo del cliente, por lo que el hardware del servidor se puede mantener bastante simple sin duda.

(vii) Apoya el desarrollo no lineal:

Git proporciona ramificaciones y fusiones rápidas y contiene herramientas particulares para visualizar y recorrer un historial de desarrollo no lineal. Una noción básica en Git es que un cambio se fusionará con más frecuencia de lo que se escribe a medida que se envía a diferentes revisores.

Las ramas de Git son extremadamente ligeras. Una rama en Git se refiere solo a una única confirmación. Se puede crear la estructura completa de la rama con la ayuda de las confirmaciones principales.

(viii) Fácil ramificación:

La administración de sucursales a través de Git es muy sencilla y sencilla. Solo requiere unos pocos segundos para crear, eliminar y fusionar ramas. Las ramas de características brindan un entorno aislado para cada cambio en su base de código.

Cuando un desarrollador requiere comenzar a trabajar en algo, independientemente del tamaño del trabajo, crea una nueva rama. Esto asegura que la rama maestra tenga constantemente un código de calidad de producción.

(ix) Desarrollo distribuido:

Git proporciona a cada desarrollador una copia local de todo el historial de desarrollo, además de que los cambios se clonan de un repositorio a otro. Estos cambios se introducen como ramas de desarrollo adicionales y se pueden fusionar de la misma manera que una rama desarrollada localmente.

(x) Compatibilidad junto con los Sistemas o Protocolo actuales:

Los repositorios se pueden publicar a través de HTTP, FTP o un protocolo Git sobre un socket simple o ssh.

P # 6) ¿Cómo se crea un repositorio en Git?

Responder: Para crear un repositorio, debe crear un directorio para el proyecto si aún no existe, y luego simplemente ejecutar el comando ' git init ”. Al ejecutar este comando, se creará un directorio .git dentro del directorio del proyecto, es decir, ahora el directorio del proyecto se ha convertido en un repositorio Git.

el mejor software espía para celulares

P # 7) ¿Qué es un directorio .git?

Responder: En el momento en que cree un repositorio, encontrará un directorio .git dentro de él. Este directorio .git contiene todos los metadatos del repositorio y mantiene un seguimiento de todos los cambios realizados en los archivos en su repositorio, manteniendo un historial de confirmaciones.

Toda la información sobre confirmaciones, ganchos, referencias, bases de datos de objetos, direcciones de repositorios remotos, etc. se guarda dentro de esta carpeta. Esta es la parte más crucial de Git. Cuando clona cualquier repositorio de Git en su máquina local, este .git es el directorio que realmente se copia.

P # 8) ¿Qué sucede si se elimina el directorio .git?

Responder: Si se elimina el directorio .git /, perderá la pista del historial de su proyecto. El repositorio ya no estará bajo control de versiones.

P # 9) ¿Qué comando se usa para escribir un mensaje de confirmación en Git?

Responder: El comando utilizado para pasar un mensaje a un git commit es git commit -m 'mensaje de confirmación'. La bandera metro se utiliza para pasar un mensaje de confirmación.

P # 10) ¿Qué es el repositorio Git básico? ¿En qué se diferencia de un repositorio Git estándar / no desnudo?

Responder: Repositorios que se crean mediante git init command son los repositorios de Git estándar / no desnudos.

En la carpeta de nivel superior de dicho repositorio, encontrará dos cosas:

1. Un subdirectorio .git que mantiene todos los metadatos y un seguimiento del historial de su repositorio.
2. Un árbol de trabajo.

Los repositorios que se crean utilizando git init –bare command se conocen como repositorios Git desnudos. Se utilizan principalmente para compartir. No contienen ningún árbol de trabajo. Mantienen el historial de revisión de git de su repositorio en la carpeta raíz en lugar de tenerlo dentro de la subcarpeta .git.

Solo contiene datos de repositorio básicos. Así es como un repositorio Git simple es diferente de un repositorio Git estándar. Además, un repositorio simple no tiene un control remoto predeterminado origen repositorio, ya que sirve como repositorio de origen para múltiples usuarios remotos.

Dado que un repositorio simple no contiene ningún espacio de trabajo, el git push y git pull los comandos no funcionan en un repositorio simple. No es necesario que confirme ningún cambio en un repositorio básico.

P # 11) Mencione algunos servicios de alojamiento de repositorios de Git.

Responder:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• FuenteForge
• Plataforma de lanzamiento
• Forzosamente
• Beanstalk
• parece

P # 12) Nombra algunas operaciones básicas en Git.

Responder: Algunas operaciones básicas en Git incluyen:

• Inicializar
• Agregar
• Cometer
• Empujar
• Jalar

P # 13) Nombra algunas operaciones avanzadas en Git.

Responder: Algunas operaciones avanzadas en Git son:

• Derivación
• Fusión
• Rebasar

P # 14) ¿Cómo distinguirá entre Git y SVN?

Responder: Git es un control de versiones distribuido, mientras que SVN está centralizado. Esto conduce a muchas diferencias entre los dos en términos de sus características y funcionalidades.

P # 15) ¿Cómo diferenciará entre Git y GitHub?

Responder: Git es un sistema de control de versiones de alta calidad. Se distribuye por naturaleza y se emplea para realizar un seguimiento de los cambios en el código fuente durante el desarrollo de software. Tiene un modelo de ramificación único que ayuda a sincronizar el trabajo entre desarrolladores y rastrear cambios en cualquier archivo.

Los objetivos principales de Git son la velocidad, la integridad de los datos y brindar soporte a flujos de trabajo distribuidos y no lineales. Git se instala y mantiene en la máquina local, en lugar de en la nube.

GitHub es un servicio de alojamiento de repositorios de Git basado en la nube que une a los equipos. Le brinda una GUI basada en la web, así como también proporciona control de acceso y muchas funciones de colaboración, herramientas fundamentales de administración de tareas para cada proyecto.

Además, GitHub es un código abierto, es decir, el código se mantiene en un servidor centralizado y todos pueden acceder a él.

P # 16) ¿Qué es un conflicto en Git y cómo resolverlo?

Responder: Git tiene una función de combinación automática que maneja las confirmaciones de combinación por sí sola, siempre que los cambios de código se hayan producido en diferentes líneas y en diferentes archivos.

Pero, en caso de competir por confirmaciones donde hay cambios en las mismas líneas de código de un archivo o un archivo ha sido eliminado en una rama pero existe y modificado en otra, Git no puede resolver automáticamente las diferencias y, por lo tanto, genera un conflicto de fusión.

En tales casos, se requiere su ayuda para decidir qué código incluir y qué código descartar en la fusión final.

Puede producirse un conflicto de fusión durante la fusión de una rama, la reestructuración de una rama o la selección de una confirmación. Una vez que se detecta un conflicto, Git resalta el área en conflicto y le pide que lo resuelva. Una vez que se resuelva el conflicto, puede continuar con la fusión.

Siga los pasos a continuación para resolver un conflicto de fusión de cambio de línea competitivo:

1. Abra Git Bash (línea de comando de Git).
2. Usar cd comando para ir al repositorio local de Git que tiene el conflicto de fusión.
3. Utilizar el estado de git comando para producir la lista de archivos afectados por el conflicto de fusión.
4. Abra el editor de texto que usa y vaya al archivo que tiene conflictos de combinación.
5. Para ver el inicio del conflicto de fusión en su archivo, busque el marcador de conflicto en el documento<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> SUCURSAL-NOMBRE.
6. Elija en caso de que necesite mantener solo los cambios de su sucursal, solo mantenga los cambios de la otra sucursal o realice un cambio nuevo, que puede incluir cambios de las dos sucursales. Borra los marcadores de conflicto<<<<<<>>>>>> y haga los cambios que necesite en la fusión final.
7. Usar agrega git. comando para agregar o organizar sus cambios.
8. Finalmente, use el git commit -m 'mensaje' comando para confirmar sus cambios con un comentario.

Para resolver el conflicto de combinación de archivos eliminados, debe seguir los pasos a continuación:

1. Abra Git Bash (línea de comando de Git).
2. Usar cd comando para ir al repositorio de Git local que tiene el conflicto de fusión.
3. Utilizar el estado de git comando para producir la lista de archivos afectados por el conflicto de fusión.
4. Abra el editor de texto que usa y vaya al archivo que tiene conflictos de combinación.
5. Elija si desea conservar el archivo eliminado. Puede verificar los últimos cambios realizados en el archivo eliminado en su editor de texto.
6. Usar git agregar comando para volver a agregar el archivo eliminado al repositorio. O usar ir rm comando para eliminar el archivo de su repositorio.
7. Finalmente, use el git commit -m 'mensaje' comando para confirmar sus cambios con un comentario.

P # 17) ¿Cómo arreglará un compromiso roto?

Responder: Para arreglar una confirmación rota o para cambiar la última confirmación, el método más conveniente es usar el comando ' git commit -amend ’ .

Le permite combinar cambios por etapas con la confirmación anterior como alternativa para crear una confirmación completamente nueva. Esto reemplaza el compromiso más reciente con el compromiso modificado.

(imagen fuente )

Mediante este comando, también puede editar el mensaje de confirmación anterior sin cambiar su instantánea.

P # 18) ¿Cuál es el uso de git instaweb?

Responder: Es un script a través del cual puede navegar instantáneamente por su repositorio de trabajo Git en un navegador web.

Este script configura gitweb y un servidor web para explorar el repositorio local. Dirige automáticamente un navegador web y ejecuta un servidor web a través de una interfaz en su repositorio local.

P # 19) ¿Qué es git is-tree?

Responder: 'Git is-tree' significa un objeto de árbol que comprende el modo y el nombre de todos los elementos junto con el valor SHA-1 del blob o del árbol.

Q #20) ¿Hay alguna forma de revertir una confirmación de git que ya se ha enviado y se ha hecho pública?

Responder: Sí, para corregir o revertir una confirmación incorrecta, hay dos enfoques que se pueden utilizar según el escenario.

Son:

1. La forma más obvia es realizar una nueva confirmación en la que elimine el archivo defectuoso o corrija los errores en él. Una vez hecho esto, puede enviarlo a un repositorio remoto.
2. Otro enfoque es crear una nueva confirmación para deshacer todos los cambios que se realizaron en la confirmación incorrecta anterior. Esto se puede hacer a través del comando git revert - ' git revert '

Q #21) ¿Cómo diferenciará entre git pull y git fetch?

Responder: Git pull El comando extrae todas las nuevas confirmaciones de una rama específica en el repositorio central y actualiza la rama de destino en su repositorio local.

Git fetch también apunta a lo mismo, sin embargo, su funcionalidad subyacente es un poco diferente. Cuando hagas un git fetch, todas las nuevas confirmaciones de una rama específica se extraerán en tu repositorio central y estos cambios se almacenarán en una nueva rama en tu repositorio local. Esto se llama rama recuperada.

Si desea ver estos cambios en su rama de destino, debe realizar una ir a fusionar después de git fetch. La rama de destino se actualizará con los últimos cambios solo después de fusionarla con la rama obtenida.

Entonces, un git pull actualiza la rama local con su versión remota, mientras que un git fetch no cambia directamente su propia rama local o copia de trabajo en refs / jefes. Git fetch se puede utilizar para actualizar sus ramas de seguimiento remoto en refs / remotes //.

En palabras simples git pull es igual a git fetch seguido de un git merge .

P # 22) ¿Cuál es el uso del área de preparación o la indexación en Git?

Responder: Desde la perspectiva de Git, hay tres áreas donde se pueden guardar los cambios del archivo, es decir, el directorio de trabajo, el área de preparación y el repositorio.

Primero, realiza cambios en el directorio de trabajo de su proyecto almacenado en el sistema de archivos de su computadora. Todos los cambios permanecen aquí hasta que los agregue a un área intermedia llamada área de preparación.

Puede organizar los cambios ejecutando git add. mando. Esta área de preparación le ofrece una vista previa de su próxima confirmación y básicamente le permite ajustar sus confirmaciones. Puede agregar o eliminar cambios en el área de preparación hasta que esté satisfecho con la versión que va a confirmar.

Una vez que verifique sus cambios y cierre la etapa modificada, finalmente podrá confirmar los cambios. Tras la confirmación, van al repositorio local, es decir, al directorio .git / objects.

Si usa Git GUI, verá la opción de organizar sus cambios. En la siguiente captura de pantalla, el archivo sample.txt se encuentra en el área de cambios sin etapas, lo que significa que está en su directorio de trabajo.

Puede seleccionar un archivo y hacer clic en 'cambio de etapa', luego se moverá al área de preparación. Por ejemplo , el archivo hello.txt está presente en el área de cambio de etapa (se confirmará). Puede verificar sus cambios y luego hacer una firma, seguida de una confirmación.

La puesta en escena también se conoce como indexación porque git mantiene un archivo de índice para realizar un seguimiento de los cambios de archivo en estas tres áreas. Los archivos que se almacenan en etapas se encuentran actualmente en su índice.

Cuando agrega cambios al área de preparación, la información en el índice se actualiza. Cuando realiza una confirmación, en realidad es lo que está en el índice lo que se confirma, y ​​no lo que está en el directorio de trabajo. Puedes usar el estado de git comando para ver qué hay en el índice.

P # 23) ¿Qué es Git Stash?

Responder: GIT stash captura el estado actual del directorio de trabajo y el índice y lo mantiene en la pila para uso futuro. Revierte los cambios no confirmados (tanto por etapas como por etapas) de su directorio de trabajo y le devuelve un árbol de trabajo limpio.

Puede trabajar en otra cosa ahora y, cuando regrese, podrá volver a aplicar estos cambios. Por lo tanto, si desea cambiar de un contexto a otro sin perder sus cambios actuales, puede usar el almacenamiento.

Es útil en el cambio de contexto rápido, cuando se encuentra a mitad de camino de un cambio de código que no desea confirmar o deshacer en este momento y tiene algo más en lo que trabajar. El comando a usar es git stash.

P # 24) ¿Qué es el Git Stash drop?

Responder: Cuando ya no necesite un alijo específico, puede eliminarlo ejecutando comando git stash drop . Si desea eliminar todas las reservas de una sola vez desde el repositorio, puede ejecutar comando git stash clear .

P # 25) ¿Qué se aplica al alijo de Git? ¿En qué se diferencia del stash pop de Git?

Responder: Ambos comandos se utilizan para volver a aplicar los cambios guardados y comenzar a trabajar desde donde lo dejó.

En aplicar git stash , los cambios se volverán a aplicar a su copia de trabajo y también se mantendrán en el alijo. Este comando se puede utilizar cuando desee aplicar los mismos cambios ocultos a varias ramas.

En git stash pop comando, los cambios se eliminan del alijo y se vuelven a aplicar a la copia de trabajo.

P # 26) ¿Cuál es el uso del comando git clone?

Responder: los clon de git El comando crea una copia del repositorio central de Git existente en su máquina local.

P # 27) ¿Cuándo se usa el comando git config?

Responder: los configuración de git El comando se usa para establecer opciones de configuración para su instalación de Git.

Por ejemplo, después de descargar Git, debe usar los siguientes comandos de configuración para configurar el nombre de usuario y confirmar la dirección de correo electrónico en Git respectivamente:

$ git config –global user.name “”

$ git config –global user.email “”

Entonces, principalmente, cosas como el comportamiento del repositorio, la información del usuario y las preferencias se pueden configurar con la ayuda de este comando.

P # 28) ¿Cómo identificará si la rama ya está fusionada con la maestra?

Responder:

Al ejecutar los siguientes comandos, puede conocer el estado de fusión de la rama:

1. git branch - maestro emergente: Esto mostrará una lista de todas las ramas que han sido renombradas como maestras.
2. git branch –merged: Esto mostrará una lista de todas las ramas que se han fusionado en HEAD.
3. git branch –no-merged: Esto mostrará una lista de todas las ramas que aún no se fusionaron.

De forma predeterminada, este comando indica el estado de fusión de las sucursales locales únicamente. Si desea conocer el estado de fusión de sucursales locales y remotas, puede usar -a bandera. Si desea verificar solo las ramas remotas, puede usar -r bandera.

P # 29) ¿Qué son los Hooks en Git?

Responder: Los ganchos de Git son ciertos scripts que Git ejecuta antes o después de un evento como confirmar, enviar, actualizar o recibir. Encontrará la carpeta 'hooks' dentro del directorio .git en su repositorio local. Encontrará los scripts incorporados aquí pre-commit, post-commit, pre-push, post push.

Estos scripts se ejecutan localmente antes o después de que ocurra un evento. También puede modificar estos scripts de acuerdo con sus necesidades y Git ejecutará el script cuando ocurra ese evento en particular.

P # 30) ¿Cuál es el uso de git fork? ¿En qué se diferencia la bifurcación de la clonación?

Responder: Bifurcar un proyecto significa crear una copia remota del lado del servidor del repositorio original. Puede cambiar el nombre de esta copia y comenzar a hacer un nuevo proyecto en torno a esto sin afectar el proyecto original. La bifurcación no es el concepto central de Git.

La operación de bifurcación es utilizada por el flujo de trabajo de Git y esta idea existe por más tiempo para software gratuito y de código abierto como GitHub. Por lo general, una vez que haya bifurcado el proyecto, rara vez volverá a contribuir al proyecto principal.

Por ejemplo, OpenBSD es un sistema operativo de código abierto similar a Unix que fue desarrollado bifurcando NetBSD, que es otro sistema operativo de código abierto similar a Unix.

Sin embargo, en la bifurcación, existe una conexión directa entre su copia bifurcada y el repositorio original. En cualquier momento, puede contribuir al proyecto original utilizando las solicitudes de extracción.

En la copia bifurcada, todos los datos principales, como códigos y archivos, se copian del repositorio original, sin embargo, las ramas, las solicitudes de extracción y otras características no se copian. La bifurcación es una forma ideal para la colaboración de código abierto.

La clonación es esencialmente un concepto de Git. Un clon es una copia local de cualquier repositorio remoto. Cuando clonamos un repositorio, todo el repositorio de origen junto con su historial y ramas se copian en nuestra máquina local.

A diferencia de la bifurcación, no existe una conexión directa entre el repositorio clonado y el repositorio remoto original. Si desea realizar solicitudes de extracción y volver al proyecto original, entonces debe agregarse como colaborador en el repositorio original.

La clonación también es una excelente manera de crear una copia de seguridad del repositorio original, ya que la copia clonada también tiene todo el historial de confirmaciones.

P # 31) ¿Cómo averiguará todos los archivos que se han cambiado en una confirmación de Git en particular?

Responder: Al usar el valor hash de la confirmación en particular, puede ejecutar el siguiente comando para obtener la lista de archivos que se han cambiado en una confirmación en particular:

git diff-tree -r {hash}

Esto mostrará una lista de todos los archivos que se han modificado y también los archivos que se han agregado. La bandera -r se usa para listar archivos individuales junto con su ruta en lugar de contraerlos solo en los nombres de su directorio raíz.

También puede utilizar el siguiente comando:

git diff-tree –no-commit-id –name-only -r {hash}

–No-commit-id volverá a entrenar los números hash de confirmación para que aparezcan en la salida. Considerando que, -name excluirá las rutas de archivo y solo dará los nombres de archivo en la salida.

Q #32) ¿Cuál es la diferencia entre git checkout (nombre de rama) y git checkout -b (nombre de rama)?

Responder: El comando git checkout (nombre de la sucursal) cambiará de una rama a otra.

El comando git checkout -b (nombre de la sucursal) creará una nueva rama y también cambiará a ella.

P # 33) ¿Qué es SubGit?

Responder: SubGit es una herramienta que se utiliza para la migración de SVN a Git. Está desarrollado por una empresa llamada TMate. Convierte los repositorios SVN a Git y le permite trabajar en ambos sistemas al mismo tiempo. Sincroniza automáticamente el SVN con Git.

(imagen fuente )

Puede crear un espejo SVN || Git usando esta herramienta. SubGit debe instalarse en su servidor Git. Detectará todas las configuraciones de su repositorio SVN remoto, incluidas las revisiones, ramas y etiquetas de SVN, y las convertirá en confirmaciones de Git.

También conserva el historial, incluido el seguimiento de los datos de combinación.

P # 34) ¿Puedes recuperar una rama eliminada en Git?

Responder: Sí tu puedes. Para recuperar una rama eliminada, debe conocer el SHA de la parte superior de su cabeza. SHA o hash es un ID único que Git crea con cada operación.

Cuando elimina una rama, aparece el SHA en la terminal:

Rama eliminada (era)

Puede usar el siguiente comando para recuperar la rama eliminada:

git checkout -b

Si no conoce el SHA para la confirmación en la punta de su rama, primero puede usar el ir a reflog comando para conocer el valor SHA y luego aplicar el comando de pago anterior para restaurar su rama.

Q # 35) ¿Qué es git diff ¿mando? ¿En qué se diferencia de git status?

Responder: Git diff es un comando multiuso que se puede ejecutar para mostrar las diferencias entre dos confirmaciones arbitrarias, cambios entre el árbol de trabajo y una confirmación, cambios entre el árbol de trabajo y un índice, cambios entre dos archivos, cambios entre el índice y un árbol, etc.

los estado de git El comando se usa para inspeccionar un repositorio. Muestra el estado del directorio de trabajo y el área de preparación. Enumerará los archivos que se han preparado, que no se han preparado y los archivos que no se han rastreado.

P # 36) ¿Qué contiene un objeto Commit?

Responder: El objeto de confirmación contiene el hash del objeto de árbol de nivel superior, el hash de confirmación de los padres (si lo hay), la información del autor y del autor, la fecha de confirmación y el mensaje de confirmación.

Puede ver esto a través del registro de git mando.

Ejemplo:

(imagen fuente )

P # 37) ¿Qué es git cherry-pick? ¿Cuáles son los escenarios en los que se puede utilizar git cherry-pick?

Responder: Git cherry-pick es un comando poderoso para aplicar los cambios introducidos por una o más confirmaciones existentes. Le permite elegir una confirmación de una rama y aplicarla a otra.

git cherry-pick commitSha es el comando que se utiliza para seleccionar. commitSha es la referencia de confirmación.

Este comando se puede utilizar para deshacer cambios. Por ejemplo, si por error se ha comprometido con una rama incorrecta, puede verificar la rama correcta y seleccionar la confirmación donde debería pertenecer.

También se puede utilizar en colaboración en equipo. Puede haber escenarios en los que se deba compartir el mismo código entre dos componentes del producto. En este caso, si un desarrollador ya ha escrito ese código, el otro puede elegir el mismo.

La selección selectiva también es útil en las revisiones de errores en las que se puede seleccionar una confirmación de parche directamente en la rama maestra para solucionar el problema lo antes posible.

P # 38) ¿Para qué se usa 'git reset'? ¿Cuál es el modo predeterminado de este comando?

Responder: Restablecimiento de Git es un comando poderoso para deshacer cambios locales en el estado de un repositorio de Git. Este comando restablece el HEAD actual a la etapa especificada.

Restablece tanto el índice como el directorio de trabajo al estado de su última confirmación. Git reset tiene tres modos, es decir, suave, duro y mixto. El modo de funcionamiento predeterminado es mixto.

P # 39) ¿Cuál es la diferencia entre 'HEAD', 'árbol de trabajo' e 'índice'?

Responder: El árbol de trabajo o espacio de trabajo es el directorio que contiene los archivos de origen en los que está trabajando actualmente.

El índice es el área de preparación en Git donde se preparan las confirmaciones. Se encuentra entre el compromiso y su árbol de trabajo. El índice Git es un archivo binario grande que incluye todos los archivos de la rama actual, sus nombres, sumas de comprobación sha1 y marcas de tiempo.

Este archivo está presente en /.git/index. HEAD es la referencia o puntero a la última confirmación en la rama de pago actual.

P # 40) ¿Cuál es la diferencia entre rebase y merge? ¿Cuándo debería volver a basarse y cuándo fusionarse?

Responder: Los comandos rebase y merge se utilizan para integrar cambios de una rama a otra, pero de una manera diferente.

Como se ve en las dos imágenes a continuación, suponga que tiene confirmaciones (esto es antes de fusionar / rebase). Después de la fusión, obtendrá el resultado como una combinación de confirmaciones. Vincula los historiales de ambas ramas y crea un nuevo 'compromiso de fusión' en la rama de funciones.

Por otro lado, rebase moverá toda la rama de características para comenzar en la punta de la rama maestra.

(imagen fuente )

Las confirmaciones se verán así:

No se recomienda cambiar la base para las sucursales públicas, ya que crea repositorios inconsistentes. Sin embargo, el rebase es una buena opción para las sucursales privadas / desarrolladores individuales. No es muy adecuado para el modo de rama por función. Pero si tiene un modelo de rama por desarrollador, el rebase no es perjudicial.

Además, el rebase es una operación destructiva, por lo que su equipo de desarrollo debe tener la habilidad suficiente para aplicarlo correctamente. De lo contrario, se puede perder el trabajo comprometido.

Además, revertir una fusión es más fácil que revertir un rebase. Por lo tanto, si sabe que puede haber posibilidades de que se requiera revertir, entonces debe usar la combinación.

Merge persevera en la historia tal como es, mientras que rebase reescribe la historia. Por lo tanto, si desea ver el historial completamente tal como ocurrió, debe usar fusionar.

P # 41) ¿Cuál es la sintaxis para rebase?

Responder: La sintaxis del comando rebase es git rebase (nueva confirmación)

P # 42) ¿Cómo eliminará un archivo de Git sin eliminarlo realmente de su sistema de archivos local?

Responder: Puede utilizar la opción 'en caché' para esto:

git rm -rf –archivos $ en caché

Este comando eliminará los archivos de su repositorio sin eliminarlos de su disco.

P # 43) ¿Cuál es el patrón de ramificación común en Git?

Responder: El patrón de ramificación común se basa en git-flow. Tiene dos ramas principales, es decir, maestría y desarrollo.

• La rama maestra contiene el código de producción. Todo el código de desarrollo se fusiona en la rama maestra en algún momento.
• La rama de desarrollo contiene el código de preproducción. Cuando se completan las funciones, se fusionan con la rama maestra, generalmente a través de una canalización de CI / CD.

Este modelo también tiene algunas ramas de apoyo que se utilizan durante el ciclo de desarrollo:

• Ramas de funciones / ramas de temas: Se utilizan para desarrollar nuevas funciones para próximas versiones. Puede ramificarse de la rama de desarrollo y debe fusionarse nuevamente con la rama de desarrollo. Generalmente, estas ramas existen solo en repositorios de desarrolladores y no en origen.
• Ramas de revisión: Se utilizan para versiones de producción no planificadas cuando es necesario corregir cualquier error crítico inmediatamente en la versión de producción en vivo. Pueden separarse del maestro y deben fusionarse nuevamente en desarrollar y maestro.
• Ramas de lanzamiento: Se utilizan para la preparación de nuevos lanzamientos de producción. La rama de lanzamiento le permite corregir errores menores y preparar metadatos para su lanzamiento. Pueden derivarse del desarrollo y deben fusionarse nuevamente en maestro y desarrollo.

Conclusión

Hemos analizado las preguntas importantes que generalmente se hacen durante las entrevistas de Git en este tutorial.

Esto no solo lo ayudará a prepararse para las próximas entrevistas, sino que también aclarará sus conceptos de git.

¡Todo lo mejor para tu entrevista!

Lectura recomendada

• Preguntas y respuestas de la entrevista
• Algunas preguntas interesantes de la entrevista sobre pruebas de software
• Las 40 preguntas y respuestas principales de las entrevistas de programación en C
• Las 40 preguntas y respuestas más populares de la entrevista J2EE que debe leer
• Preguntas y respuestas de la entrevista de prueba ETL
• Más de 20 preguntas y respuestas de entrevistas de salida más frecuentes
• Principales preguntas de la entrevista sobre formularios e informes de Oracle
• Algunas preguntas y respuestas complicadas sobre pruebas manuales