Как я проверяю удаленное ответвление Мерзавца?
Для инструментов, которые генерируют исполняемые файлы (например, скрипты), может оказаться полезным следующий код:
def make_executable(path):
mode = os.stat(path).st_mode
mode |= (mode & 0o444) >> 2 # copy R bits to X
os.chmod(path, mode)
Это делает его (более или менее) уважающим umask, который действовал, когда файл был создан: Исполняемый файл установлен только для тех, которые могут быть прочитаны.
Использование:
path = 'foo.sh'
with open(path, 'w') as f: # umask in effect when file is created
f.write('#!/bin/sh\n')
f.write('echo "hello world"\n')
make_executable(path)
6 ответов
Обновление
Ответ Якуба на самом деле улучшает это. В версиях Git ≥ 1.6.6, имея только один пульт, вы можете просто сделать:
git fetch
git checkout test
Как указывает пользователь Masukomi в комментарии, git checkout test НЕ будет работать в современном git, если у вас несколько пультов . В этом случае используйте
git checkout -b test <name of remote>/test
или сокращенное обозначение
git checkout -t <name of remote>/test
Старый ответ
Прежде чем вы сможете начать локальную работу с удаленной веткой, вам необходимо получить его, как указано в ответах ниже.
Чтобы получить ветку, вам просто нужно:
git fetch origin
Это извлечет для вас все удаленные ветки. Вы можете увидеть ветки, доступные для оформления заказа, с помощью:
git branch -v -a
Имея под рукой удаленные ветки, вам теперь нужно проверить интересующую вас ветку, предоставив вам локальную рабочую копию:
git checkout -b test origin/test
Существует много альтернатив, например:
-
Альтернативный 1:
git fetch && git checkout testЭто - самый простой путь.
-
Альтернативные 2:
git fetch git checkout testЭто - то же, но в два погружается.
Для нас это кажется remote.origin.fetch, конфигурация дала проблему. Поэтому мы не видели никакие другие удаленные ответвления, чем master, таким образом git fetch [--all] не помог. Ни git checkout mybranch, ни git checkout -b mybranch --track origin/mybranch действительно работал, хотя это, конечно, было в удаленном.
предыдущая конфигурация только позволила master быть выбранной:
$ git config --list | grep fetch
remote.origin.fetch=+refs/heads/master:refs/remotes/origin/master
Фиксируют его при помощи * и выбирают новую информацию от источника:
$ git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
$ git fetch
...
* [new branch] ...
...
Теперь мы могли git checkout удаленное ответвление локально.
Никакая идея, как эта конфигурация закончилась в нашем локальном repo.
для получения всех удаленных ответвлений используют это:
git fetch --all
затем контроль к ответвлению:
git checkout test
Примечание: В современном Git (> = 1.6.6 ) вы можете использовать только
git checkout test
(обратите внимание, что это «тест», а не 'origin / test'), чтобы выполнить магическую DWIM -mery и создать для вас локальную ветвь 'test', для которой восходящим потоком будет ветка с удаленным отслеживанием 'origin / test'.
* (без ветки) в вывод git branch означает, что вы находитесь в безымянной ветке, в так называемом состоянии «отсоединенной HEAD» (HEAD указывает непосредственно на фиксацию, а не является символической ссылкой на некоторую локальную ветку ). Если вы сделали несколько коммитов в этой безымянной ветке, вы всегда можете создать локальную ветвь вне текущей фиксации:
git checkout -b test HEAD
В этом случае вы, вероятно, захотите создать локальную ветвь test , которая отслеживает удаленную ветвь test :
$ git branch test origin/test
В более ранних версиях git , вам нужен явный параметр - track , но теперь он используется по умолчанию, когда вы переходите от удаленной ветви.