Como faço para criar um script Bash para o Git Checkin / Checkout?

Question

Eu estava pensando em trazer um serviço git em um servidor Ubuntu. No entanto, a maneira como eu e outro programador operamos - realmente queremos tentar nos ater a uma pessoa trabalhando em um projeto de cada vez.

Como eu faria um script Bash para criar um check-in e check-out com o git? Queremos evitar que alguém faça o check-in de um código que ainda não tenha sido verificado, e isso deve resultar em um erro com o nome da pessoa que fez o check-out.

EDIT: Eu não estou realmente interessado em usar o Git com seus fantásticos recursos de diferenças. Eu movo 100 mph e não tenho tempo para jogar jogos de diferenças com os outros desenvolvedores. É por isso que estamos usando o Git. Se os outros desenvolvedores quiserem jogar o jogo diff, eles ainda podem fazer isso. Mas quando eu verifico algo, quero que ele seja bloqueado para todos até que eu verifique novamente.

    

Answer 1

But when I check something out, I want it locked to everyone until I check it back in again.

Errr ... desculpe, não é assim que funciona um DVCS (com um D como "Distributed").

a / você não "registra" um arquivo (como você faria no ClearCase, por exemplo). Você acabou de começar a modificá-lo, e o Git detectará a mudança como candidata a indexação ( git add ) e a confirmar ( git commit , a parte "verificação")

b / Quando você faz o "checkout" (ou seja, modifica) ou verifica um arquivo, os outros desenvolvedores, com seus outros repositórios associados, não sabem nada sobre isso.
Você está "travando" todo mundo para que todos não possam acessar seu repositório e modificar seus arquivos.

Mas quando você publica (ou seja, envia essas alterações), então você precisa resolver qualquer modificação concorrente. Em um DVCS, não há um referencial central capaz de detectar uma alteração concorrente e / ou registrar um "bloqueio".

    

Answer 2

Não é exatamente assim que o git foi projetado para funcionar. Ou seja, não é o fluxo de trabalho típico do git. Se você realmente quiser esse fluxo de trabalho, considere usar algo criado em torno desse tipo de fluxo de trabalho, como SubVersão. Os arquivos bloqueados resultam em notificações, caso alguém deseje o arquivo, mas você é o proprietário do arquivo:

link

Eu não sei se o gateway git-svnserver suporta bloqueio, mas pode. Se isso acontecer, então você pode ter o melhor dos dois mundos.

O Git é muito flexível, no entanto. Se você quer ser malvado, vai apoiar isso. O Git permite que você limpe cegamente as alterações de outras pessoas que possam ter ocorrido enquanto você estava usando o arquivo. Toda vez que você quiser enviar para o repositório principal, faça:

git pull --strategy ours ; git push

Não há necessidade desse recurso de mesclagem.

Esse par de comandos levará suas alterações ao servidor, ignorando as alterações que outras pessoas fizeram desde sua última sincronização.

Outra opção a considerar é "git pull --strategy recursive -Xours".

    

Answer 3

A comunicação com o outro programador é uma opção? Para uma pequena equipe que é quase certamente uma maneira melhor do que depender de bloqueio.

Se você insistir em bloquear, o modelo distribuído do Git não é um bom ajuste. Ao invés do Git, você deve provavelmente usar um sistema de controle de versão centralizado , como o SVN. Isso permite que você bloqueie os arquivos no repositório. Seu colega programador receberá um aviso quando ele tentar se comprometer com o repositório.

    

Answer 4

Você realmente não precisa disso. Git e outros bons sistemas de controle de origem lidam com fusões bem o suficiente para que você não precise bloquear arquivos no checkout. Em vez disso, certifique-se de que você faça commits frequentes e envie regularmente as alterações para o autor.

Quanto a escrever um script para check-in e check-out, você sempre pode escrever um script como qualquer outra coisa ... apenas uma série de comandos como você os executaria na linha de comando, mas novamente você não precisa disso . Você só precisa de um comando para atualizar seu repositório local, um comando para commit e um comando para push upstream. Seria aconselhável que você aprendesse o git primeiro e, em seguida, considerasse o script mais tarde, quando você encontrar uma tarefa tediosa para executar como comandos individuais.