ver tipos tag modificados etiquetas crear archivos git github githooks github-api

tipos - ¿Hay alguna forma de bloquear archivos individuales o directorios en la horquilla cuando se usa github?



git ver archivos modificados (6)

Somos un equipo de más de 60 desarrolladores trabajando en el mismo producto y estamos pasando de SVN a Github. Tenemos un proceso en SVN donde los archivos individuales están bloqueados y cada vez que un desarrollador desea codificar, necesita que el propietario del archivo lo desbloquee. Tres de nosotros somos los dueños del total de más de 150 archivos. El desbloqueo va precedido de una revisión del código.

En Github, estamos planeando utilizar el modelo de Fork-Clone: ​​cada proyecto en el que un grupo de desarrolladores está trabajando hará una bifurcación, cada desarrollador hará un clon de la bifurcación, escribirá el código y se comprometerá con el origen, el líder de la la característica hará una solicitud de extracción hacia la corriente ascendente.

Aunque parece estar bien, el problema es que cuando se entrega un gran proyecto, trae muchos cambios para su revisión y, por lo tanto, aumenta la carga para los propietarios de los archivos. Además, esto podría suceder en los últimos ciclos de desarrollo y, por lo tanto, el proyecto podría verse comprometido.

Un método que pensamos que podría funcionar es tener ganchos cuando el git push se hace al origen (fork). Puede haber una revisión final git pull upstream.

Sin embargo, no pudimos encontrar ninguna extensión de Github o ganchos de inserción para el mismo. ¿Hay una manera rápida (leer, extensión existente) de hacer esto con Github o deberíamos usar los mismos ganchos que usaríamos con git?

Este caso de uso es una de las razones por las que Git es mucho mejor que SVN -> rebase ! Si sigue un buen flujo de trabajo de git, rebase desde la corriente ascendente antes de enviar sus solicitudes de extracción. No necesita preocuparse por el bloqueo de archivos y pisotear los commits y conflictos de fusión de otra persona, etc ... una rebase deja su trabajo a un lado, aplica los commit remotos y luego aplica su trabajo en la parte superior.

Creo que esto solo requiere un replanteamiento en su proceso y confiar en las fortalezas de git versus force que encajan en un flujo de trabajo de Subversion sobre git. Su modelo de "clon de horquilla" también podría necesitar otro aspecto. Muy a menudo, cada desarrollador tiene su propio tenedor, puede compartir repos mediante controles remotos entre equipos si lo desea. Pero los contribuyentes que comparten el mismo origen establecen algunos malos hábitos.

Gitflow es un flujo de trabajo git muy popular, y Github tiene algunos buenos consejos y comparte su flujo de trabajo .

No es posible, si el archivo no se puede fusionar y necesita bloquearlo, use una solución centralizada en lugar de GIT, es decir, SVN o ClearCase.

No está exactamente bloqueado, pero Github ha introducido un concepto llamado " Propietarios de código ". Le permite restringir parte de su base de código para permitir solo confirmaciones después de la revisión por parte de los propietarios del código

No hay forma de hacerlo en Git. Como dijeron otros, si el documento es "mergable", puede intentar volver a basarlo, cambiando la forma en que actúa. En nuestro caso, tenemos una convención: si REALMENTE necesita bloquearlo, cámbiele el nombre. Pero solo hacemos tales cosas en documentos de oficina, etc.
Esta constribución no está dando una solución, es un truco de solución (pero no me permite agregar esto como un comentario.

Si está utilizando git LFS (que es compatible con algunos proveedores de hosting git, como GitHub) puede usar File Locking .

Marque un tipo de archivo como bloqueable editando el archivo .gitattributes :

*.docx lockable # Make MS Word files lockable

Y bloquearlo con:

$ git lfs lock example.docx

Puede desbloquear sus archivos con git lfs unlock example.docx y los de otra persona agregando --force .