Wdrażanie projektu przy użyciu Git push

Używając pliku post-update poniżej:

/ Align = "left" / git directory to your web server

1. Na twojej lokalnej kopii, zmodyfikuj swoją .plik git/config i dodaj swój serwer WWW jako zdalny:

   [remote "production"]
       url = username@webserver:/path/to/htdocs/.git
   

2. Na serwerze zastąp .git / hooks / post-update z pliku poniżej

3. Dodaj execute access do pliku (ponownie na serwerze):

   chmod +x .git/hooks/post-update
   

4. Teraz wystarczy lokalnie nacisnąć na serwer WWW i powinien on automatycznie zaktualizować kopia robocza:

   git push production
   

#!/bin/sh
#
# This hook does two things:
#
#  1. update the "info" files that allow the list of references to be
#     queries over dumb transports such as http
#
#  2. if this repository looks like it is a non-bare repository, and
#     the checked-out branch is pushed to, then update the working copy.
#     This makes "push" function somewhat similarly to darcs and bzr.
#
# To enable this hook, make this file executable by "chmod +x post-update". 
git-update-server-info 
is_bare=$(git-config --get --bool core.bare) 
if [ -z "$is_bare" ]
then
      # for compatibility's sake, guess
      git_dir_full=$(cd $GIT_DIR; pwd)
      case $git_dir_full in */.git) is_bare=false;; *) is_bare=true;; esac
fi 
update_wc() {
      ref=$1
      echo "Push to checked out branch $ref" >&2
      if [ ! -f $GIT_DIR/logs/HEAD ]
      then
             echo "E:push to non-bare repository requires a HEAD reflog" >&2
             exit 1
      fi
      if (cd $GIT_WORK_TREE; git-diff-files -q --exit-code >/dev/null)
      then
             wc_dirty=0
      else
             echo "W:unstaged changes found in working copy" >&2
             wc_dirty=1
             desc="working copy"
      fi
      if git diff-index --cached HEAD@{1} >/dev/null
      then
             index_dirty=0
      else
             echo "W:uncommitted, staged changes found" >&2
             index_dirty=1
             if [ -n "$desc" ]
             then
                   desc="$desc and index"
             else
                   desc="index"
             fi
      fi
      if [ "$wc_dirty" -ne 0 -o "$index_dirty" -ne 0 ]
      then
             new=$(git rev-parse HEAD)
             echo "W:stashing dirty $desc - see git-stash(1)" >&2
             ( trap 'echo trapped $$; git symbolic-ref HEAD "'"$ref"'"' 2 3 13 15 ERR EXIT
             git-update-ref --no-deref HEAD HEAD@{1}
             cd $GIT_WORK_TREE
             git stash save "dirty $desc before update to $new";
             git-symbolic-ref HEAD "$ref"
             )
      fi 
      # eye candy - show the WC updates :)
      echo "Updating working copy" >&2
      (cd $GIT_WORK_TREE
      git-diff-index -R --name-status HEAD >&2
      git-reset --hard HEAD)
} 
if [ "$is_bare" = "false" ]
then
      active_branch=`git-symbolic-ref HEAD`
      export GIT_DIR=$(cd $GIT_DIR; pwd)
      GIT_WORK_TREE=${GIT_WORK_TREE-..}
      for ref
      do
             if [ "$ref" = "$active_branch" ]
             then
                   update_wc $ref
             fi
      done
fi

Po wielu fałszywych startach i ślepych zaułkach, w końcu jestem w stanie wdrożyć kod strony za pomocą " git push remote" dzięki Ten artykuł .

Skrypt post-update autora ma tylko jedną linię I jego rozwiązanie nie wymaga .konfiguracja htaccess do ukrycia repo Git tak jak inne.

Kilka przeszkód, jeśli wdrażasz to na instancji Amazon EC2;

1) Jeśli używasz sudo do tworzenia repozytorium docelowego, musisz zmienić właściciela repo na EC2-user albo push się nie powiedzie. (Spróbuj "chown ec2-user:ec2-user repo.")

2) naciśnięcie nie powiedzie się, jeśli nie skonfigurujesz wstępnie lokalizacji swojego amazon-private-key .pem, w /etc/ssh/ssh_config jako parametr IdentityFile lub w ~/.ssh / config używając układu "[Host] - HostName - IdentityFile - User" opisanego tutaj ...

...Jednak jeśli Host jest skonfigurowany w~/.ssh / config i inna niż nazwa hosta Git push zawiedzie. (To pewnie Git bug)

Dont install git on a server or copy the .tam jest folder git. aby zaktualizować serwer z git clone możesz użyć następującego polecenia:

git ls-files -z | rsync --files-from - --copy-links -av0 . [email protected]:/var/www/project

Być może będziesz musiał usunąć pliki, które zostały usunięte z projektu.

To kopiuje wszystkie sprawdzone pliki. rsync używa ssh, który i tak jest zainstalowany na serwerze.

Im mniej oprogramowania zainstalowałeś na serwerze, tym jest on bezpieczniejszy i tym łatwiej jest zarządzać jego konfiguracją i dokumentować ją. nie ma też potrzeby zachowaj kompletny git clone na serwerze. to tylko sprawia, że bardziej skomplikowane, aby zabezpieczyć wszystko prawidłowo.

W zasadzie wszystko, co musisz zrobić, to:

server = $1
branch = $2
git push $server $branch
ssh <username>@$server "cd /path/to/www; git pull"

Mam te linie w mojej aplikacji jako plik wykonywalny o nazwie deploy.

Więc kiedy chcę wykonać deploy, wpisuję ./deploy myserver mybranch.

Sposób w jaki to robię jest taki, że mam gołe repozytorium Git na moim serwerze deployment, gdzie wypycham zmiany. Następnie loguję się na serwer wdrożeniowy, zmieniam na rzeczywisty katalog dokumentów serwera WWW i wykonuję git pull. Nie używam żadnych hooków, aby spróbować zrobić to automatycznie, to wydaje się więcej kłopotów niż jest warte.

git config --local receive.denyCurrentBranch updateInstead

Dodany w Git 2.3, to może być dobra możliwość: https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Ustawiasz go w repozytorium serwera, a także aktualizuje działające drzewo, jeśli jest czyste.

Nastąpiła dalsza poprawa w 2.4 z push-to-checkout hook and handling of unborn branches.

Przykładowe użycie:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Wyjście:

a
b

To ma następujące niedociągnięcia wspomniane w ogłoszeniu na Githubie :

• Twój serwer będzie zawierałkatalog git zawierający całą historię twojego projektu. Prawdopodobnie chcesz upewnić się, że nie może być obsługiwany przez użytkowników!
• podczas wdrożeń użytkownicy będą mogli chwilowo napotkać witrynę w niespójnym stanie, z niektórymi plikami w starej wersji, a innymi w nowej wersji, a nawet plikami w połowie zapisanymi. Jeśli jest to problem dla Twojego projektu, push-to-deploy to pewnie nie dla Ciebie.
• jeśli twój projekt potrzebuje kroku "build", będziesz musiał skonfigurować go jawnie, być może poprzez githooks.

Ale wszystkie te kwestie są poza zakresem Git i muszą być objęte zewnętrznym kodem. Więc w tym sensie, to, wraz z git hooks, są ostatecznym rozwiązaniem.

Aktualizacja: używam teraz Lloyd Moore rozwiązanie z kluczem agenta ssh -A .... Popychanie do głównego repo, a następnie wyciąganie z niego równolegle ze wszystkich maszyn jest nieco szybsze i wymaga mniej konfiguracji na tych maszynach.

Będziesz potrzebował następującego wpisu w swoim lokalnym .git / config

[remote "amazon"]
    url = amazon:/path/to/project.git
    fetch = +refs/heads/*:refs/remotes/amazon/*

Ale hej, co to jest amazon:? W Twoim lokalnym ~/.ssh/config musisz dodać następujący wpis:

Host amazon
    Hostname <YOUR_IP>
    User <USER>
    IdentityFile ~/.ssh/amazon-private-key

Teraz możesz zadzwonić

git push amazon master
ssh <USER>@<YOUR_IP> 'cd /path/to/project && git pull'

(BTW: / path / to / project.git różni się od rzeczywistego katalogu roboczego / path / to / project)

Dla Scenariusza Rozmieszczenia

W naszym scenariuszu przechowujemy kod na github / bitbucket i chcemy go wdrożyć na serwerach na żywo. W tym przypadku działa dla nas następująca kombinacja (jest to remix bardzo upvoted odpowiedzi tutaj):

1. skopiuj katalog .git Na serwer WWW
2. na twojej lokalnej kopii git remote add live ssh://user@host:port/folder
3. na pilota: git config receive.denyCurrentBranch ignore

4. Na zdalnym: nano .git/hooks/post-receive i dodaj to treść:

   #!/bin/sh GIT_WORK_TREE=/var/www/vhosts/example.org git checkout -f

5. Na pilota: chmod +x .git/hooks/post-receive

6. Teraz możesz tam wcisnąć git push live

Uwagi

• to rozwiązanie działa ze starszymi wersjami Gita (testowanymi z 1.7 i 1.9)
Na początku musisz upewnić się, że pcha się do github/bitbucket, więc będziesz miał spójne repo na żywo]}

• Jeśli twój folder .git znajduje się w katalogu głównym dokumentu, upewnij się, że Ukryłeś go z zewnątrz, dodając do .htaccess (źródło):

  RedirectMatch 404 /\..*$

Używamy capistrano do zarządzania wdrożeniem. Budujemy capistrano do wdrożenia na serwerze pośredniczącym, a następnie uruchamiamy rsync z całym naszym serwerem.

cap deploy
cap deploy:start_rsync (when the staging is ok)

cap deploy:rollback
cap deploy:start_rsync

Giddyup są językowo-agnostykami just-add-water Git Hooki do automatyzacji wdrażania za pomocą git push. Pozwala również mieć niestandardowe Hooki start/stop do ponownego uruchomienia serwera www, rozgrzewania pamięci podręcznej itp.

Https://github.com/mpalmer/giddyup

Zobacz przykłady .

Wygląda na to, że powinieneś mieć dwie kopie na serwerze. Gołą kopię, z której możesz wypchnąć / wyciągnąć, a następnie sklonować ją do swojego katalogu i skonfigurować cronjob, aby codziennie aktualizować git pull z twojego katalogu.

Można by założyć git hook, że gdy say commit zostanie utworzony, aby powiedzieć" stabilną " gałąź, to będzie ciągnąć zmiany i zastosować je do strony PHP. Dużym minusem jest to, że nie będziesz miał dużej kontroli, jeśli coś pójdzie nie tak i doda to czasu Twoim testom - ale możesz zorientować się, ile pracy będzie zaangażowanych, gdy połączysz say swoją gałąź bagażnika z stabilną gałęzią, aby dowiedzieć się, ile konfliktów możesz napotkać. Ważne będzie, aby mieć oko na wszelkie pliki które są specyficzne dla witryny (np. pliki konfiguracyjne), chyba że zamierzacie uruchomić tylko jedną witrynę.

Ewentualnie czy przyjrzałeś się przesunięciu zmiany na stronie zamiast?

Informacje o hookach Gita znajdziesz w dokumentacjigithooks .

Moje podejście do chrześcijan rozwiązanie.

git archive --prefix=deploy/  master | tar -x -C $TMPDIR | rsync $TMPDIR/deploy/ --copy-links -av [email protected]:/home/user/my_app && rm -rf $TMPDIR/deploy

• archiwizuje gałąź master do tar
• rozpakowuje archiwum tar do katalogu deploy w folderze system temp.
• rsync zmienia się na Serwer
• Usuń katalog wdrożenia z folderu temp.

Używam następującego rozwiązania przez toroid.org , który ma prostszy skrypt Hooka.

Na serwerze:

$ mkdir website.git && cd website.git
$ git init --bare
Initialized empty Git repository in /home/ams/website.git/

I zainstaluj hook na serwerze:

$ mkdir /var/www/www.example.org
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/www.example.org git checkout -f
GIT_WORK_TREE=/var/www/www git clean -f -d # clean directory from removed files

$ chmod +x hooks/post-receive

Na Twoim kliencie:

$ mkdir website && cd website
$ git init
Initialized empty Git repository in /home/ams/website/.git/
$ echo 'Hello, world!' > index.html
$ git add index.html
$ git commit -q -m "The humble beginnings of my web site."

$ git remote add web ssh://server.example.org/home/ams/website.git
$ git push web +master:refs/heads/master

Następnie, aby opublikować, wpisz

$ git push web

Na stronie znajduje się pełny opis: http://toroid.org/ams/git-website-howto

Jako odpowiedź uzupełniającą chciałbym zaproponować alternatywę. Używam git-ftp i działa dobrze.

Https://github.com/git-ftp/git-ftp

Łatwy w użyciu, tylko wpisz:

git ftp push

I git automatycznie załaduje pliki projektu.

Pozdrawiam

Biorąc pod uwagę środowisko, w którym wielu programistów ma dostęp do tego samego repozytorium, poniższe wytyczne mogą pomóc.

Upewnij się, że masz uniksową grupę, do której należą wszystkie devs i nadaj jej prawa własności .repozytorium git do tej grupy.

1. W ...git / config repozytorium Serwera set sharedrepository = true. (Mówi to git, aby zezwalał wielu użytkownikom, co jest potrzebne do zatwierdzania i wdrażania.

2. Ustawia umask każdego użytkownika w jego bashrc pliki mają być takie same-002 to dobry początek

W końcu stworzyłem własne podstawowe narzędzie do wdrażania, które automatycznie pobierałoby nowe aktualizacje z repo- https://github.com/jesalg/SlimJim - zasadniczo nasłuchuje github Post-receive-hook i używa proxy do uruchomienia skryptu aktualizacji.

Używam dwóch rozwiązań dla Hooka po odbiorze:

WDROŻENIE ROZWIĄZANIA 1

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 1 

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi
done

WDROŻENIE ROZWIĄZANIA 2

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 2

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    export GIT_TEMP_DIR1=/tmp/deploy1
    export GIT_TEMP_DIR2=/tmp/deploy2
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo "GIT TEMP DIR1:  $GIT_TEMP_DIR1/"
    echo "GIT TEMP DIR2:  $GIT_TEMP_DIR2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR1; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR1/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET1/.
        rsync $GIT_TEMP_DIR1/. -v -q --delete --delete-after -av $GIT_TARGET1/.
        rm -rf $GIT_TEMP_DIR1
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR2; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR2/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET2/.
        rsync $GIT_TEMP_DIR2/. -v -q --delete --delete-after -av $GIT_TARGET2/.
        rm -rf $GIT_TEMP_DIR2
    fi
done

Oba rozwiązania bazują na wcześniejszych rozwiązaniach dostępnych w tym wątku.

Uwaga, BRANCH_REGEX= ' ^${GIT_BRANCH1}.$' filtruje nazwy gałęzi pasujące do łańcucha" master "lub" dev* " i wdraża drzewo Robocze, jeśli popchnięta gałąź pasuje. Umożliwia to wdrożenie wersji dev i master do różnych miejsca.

DEPLOY SOLUTION 1 usuwa tylko pliki, które są częścią repo i zostały usunięte przez commit. Jest to szybsze niż rozwiązanie wdrożeniowe 2.

DEPLOY SOLUTION 2 ma tę zaletę, że usunie wszystkie nowe pliki z katalogu produkcyjnego, który został dodany po stronie serwera, bez względu na to, czy został dodany do repo czy nie. To będzie zawsze czyste dupe repo. Jest to wolniejsze rozwiązanie niż Deployment Solution 1.