Внесіть файл до іншої філії без оформлення замовлення

Чи можна зафіксувати файл у гітарному відділенні без перевірки цієї гілки? Якщо так, то як?

По суті я хочу, щоб я міг зберігати файл у своєму розділі сторінок github без постійного перемикання філій. Будь-які думки?

Update: It's not possible to do what I want (see comments below for use case). What I ended up doing is programmatically cloning my current directory to a tmp directory, then checking out my branch in that tmp directory (doesn't affect my working directory) and committing my files to the tmp directory clone. When I'm done, I push back to my working directory and delete the tmp directory. Sucks, but it's the only way to commit files to another branch without changing the current working branch of the working directory. If anyone has a better solution, please feel free to add it below. If it's better than 'it cannot be done', I'll accept yours.

27
Немає нічого поганого, якщо робити щось у клоні; якщо вони локальні, він буде використовувати жорсткі посилання, і ви навіть не займаєте додаткове місце на диску, окрім додаткової копії дерева. Якщо ви не хочете, щоб ви натискали/тягнули, ви можете використовувати git-new-workir , щоб дві робочі дерева розділяли репо через символічні посилання в .git.
додано Автор Cascabel, джерело
Неможливо зробити щось подібне до git commit-b branch_name ... .
додано Автор wkl, джерело
@KingCrunch: Захоплення подібним чином, без складання та тестування, є небезпечною практикою розвитку
додано Автор CharlesB, джерело
@Schneems: Схоже, ви робите це неправильно, будь ласка, додайте більше деталей до цього робочого процесу, я не зовсім розумію, що ви робите точно
додано Автор CharlesB, джерело
Для мене найкращий спосіб зробити це - зберегти другий клон із правильною гілкою, з якою ви перевірено. Оскільки каталозі .git стискається, а гілки сторінок найчастіше привабливі, він не буде споживати забагато дискового простору, якщо це завжди турбота. І так, єдине, що вам потрібно зробити, це перейти до потрібного каталогу. Не потрібно натискати його на інший клон і зробити "складний танець клонів", просто натискайте його в Інтернеті, як завжди, і ви могли б зрештою синхронізувати інший клон за допомогою простого завантаження.
додано Автор Jean-Bernard Jansen, джерело
Один користування є тим, що я знайшов помилку, зробив швидке виправлення, але хотів би натискати його на develop замість поточної гілки випуску. Принаймні, це причина, чому я пропустив цю функцію;)
додано Автор KingCrunch, джерело
@gustavotkg я програмно синхронізую файли з гілкою гітюби сторінок у фоновому режимі. Мені потрібно це робити, не перевіряючи філію, оскільки перевірка галузі вплине на поточну галузь користувачів. Зараз я роблю складний танець клонів і темпдірів і натискає, коли все, що я дійсно хочу зробити, це додати один файл, не впливаючи на поточну гілку користувача.
додано Автор Schneems, джерело
Чому ви не хочете перевірити іншу філію? Це тому, що у вас є нездійснені зміни?
додано Автор gustavotkg, джерело
@Schneems Ви можете мати ще одну копію репо для використання у фоновому режимі, а іншу - для використання користувачем. Таким чином, ви можете натискати зміни репо у фоновому режимі на робочу репо користувача, використовуючи посилання на гілки
додано Автор gustavotkg, джерело
@KingCrunch ви можете використовувати git stash , git checkout develop , виправити помилку, git commit , git checkout - а потім git stash pop , щоб ви повернули свої зміни
додано Автор gustavotkg, джерело

9 Відповіді

Це неможливо.

Зміни, які ви берете, пов'язані з поточною робочою копією. Якщо ви хочете здійснити зобов'язання в іншій галузі, це означає, що ви можете вносити зміни з вашої робочої копії, але базувати їх з іншого стану копії.

Це не є природним способом версії вашої роботи, і саме тому вам потрібно виконати різні кроки (зміни у стилі, перевірка гілки, поп-стиш і фіксація).

Що стосується вашого конкретного випадку використання, простий спосіб полягає в тому, щоб зберегти дві копії вашої роботи, один відібраний у гілці master , а інший - у гілці pages .

У робочій копії pages додайте копію master як віддалене репо.

  • You commit pages on master
  • Pull from master on the pages copy
  • push to GitHub
  • reset the master branch at its previous state.
16
додано
Як правильна ця відповідь? Зміни, внесені вами, не мають нічого спільного з вашою робочою копією. Вони повністю ґрунтуються на тому, що додано до індексу. Ви можете видалити все у своєму дереві робочого дерева і ще git commit , ніби нічого не сталося, тому що git дивиться лише на індекс.
додано Автор Mehrdad, джерело
Подивіться відповіді Чарлза Бейлі нижче!
додано Автор jbenet, джерело
Просто цікаво: навіщо підтримувати окремий розділ сторінок?
додано Автор CharlesB, джерело
Можна читати файли з іншої галузі, не перевіряючи їх, тому я сподівався, що буде можливість писати в іншу філію без оформлення замовлення. Хоча я розумію, що це не "природно", я використовую GIT як магазин даних, а не як чистий контроль версії в цій ситуації. У мене є обхідний шлях (див. Мій коментар вище), але він досить грубий і схильний до помилок.
додано Автор Schneems, джерело
pages.github.com це спосіб подання HTML-вмісту, такого як документи або демонстраційна сторінка, безпосередньо за допомогою github. Вона повинна бути в окремій гілці, тому що це написано гітхубом. Хоча дані (документи в даному випадку) пов'язані з проектом, він не обов'язково повинен бути в основній гілці з ряду причин, переважна кількість повідомлень майстра з змінами, не пов'язаними з кодом, який є одним з них.
додано Автор Schneems, джерело

Це може бути зроблено шляхом повторної реалізації git commit.

This can be done with various call to git hash-object

Але це важко досягти.

Будь ласка, прочитайте progit chapter 9 , щоб отримати докладнішу інформацію та повний приклад того, як імітувати вчинити

11
додано

Поки у вашому поточному індексі немає нічого, що відрізняється від вашого HEAD , який ви хочете зберегти, ви можете отримати щось подібне. (Якщо ви хочете зберегти свій індекс, ви можете тимчасово експортувати змінну середовища GIT_INDEX_FILE , щоб вказати на тимчасовий файл протягом тривалості цих команд.)

# Reset index and HEAD to otherbranch
git reset otherbranch

# make commit for otherbranch
git add file-to-commit
git commit "edited file"

# force recreate otherbranch to here
git branch -f otherbranch

# Go back to where we were before
# (two commits ago, the reset and the commit)
git reset [email protected]{2}

Ми ніколи не перевірили otherbranch , і наші файли робочого дерева не були зачеплені.

8
додано

Як сказали кілька інших, це буквально можливо, але непрактично.

Однак, оскільки Git 2.5 (з деякими важливими виправленнями в 2.6 і незначні з тих пір), є практичним способом для цього, використовуючи git worktree add .

Скажімо, наприклад, що ви хочете працювати з розділами main і doc "одночасно, або відгалуженнями develop і test , але в обох галузях навмисно містяться різні речі. (Наприклад, гілка doc має документацію, яка існує поза межами коду або поруч із ним, або гілка test має тести, які будуть виконуватись проти коду, але не розподілені, або які, як очікується, мають невдачі, для яких тести навмисно пропущені на стороні develop або будь-який інший.)

Замість того, щоб:

git clone -b develop  theclone

а потім працювати в theclone з постійним перемиканням між двома гілками, ви б:

git clone -b develop  theclone

але з іншого боку:

cd theclone
git worktree add ../ct test  # check out branch test in ../ct

або просто:

git worktree add ../test     # check out branch test in ../test

Тепер ви можете запустити свої тести в ../ test під час розробки в theclone . Ви можете об'єднати та/або змінювати зміни з однієї гілки на інший за звичайним способом: основний репозиторій вже використовується, тому не потрібно git push або git fetch . Ви просто перевіряли обидва філій на двох окремих робочих деревах, з назвою theclone і test з верхнього рівня.

7
додано

Я не можу погодитися з тим, що це неможливо. git checkout , git add < git stash push , git stash pop , git checkout /code> і git commit це можливо.

How I understand problem:

Ви знаходитесь на гілці майстра, і ви внесли деякі зміни до файлу patched.txt , і ви хотіли б передавати цей файл іншому розділу.

What you would like to do is:

  • save all changes in this repo by doing git stash
  • checkout file.txt from stashed stack
  • add file patched (and only this file) to new branch
  • get back to state of repo before modyfing file.txt

Це можна досягти, виконавши наступні команди:

destBranch=patch
thisBranch=master
FileToPutToOtherBranch="file1.txt file2.txt 'file with space in name.txt'"
message="patched files $FileToPutToOtherBranch"
                                                                                  #assumption: we are on master to which modifications to file.txt should not belong
git stash &&\                                                                     #at this point we have clean repository to $thisBranch
git checkout -b $destBranch &&\           
git checkout [email protected]{0} -- $FileToPutToOtherBranch &&                              #if there are many files, repeat this step                                         #create branch if does not exist (param -b)
git add $FileToPutToOtherBranch &&\                                               # at this point this is equal to git add . --update
git commit -m "$message" &&\
git checkout $thisBranch &&\
git stash apply &&\                                                               # or pop if want to loose backup
git checkout $thisBranch -- $FileToPutToOtherBranch                               # get unpatched files from previous branch

The reason why I am using "&&" and the end is if somebody will copy&paste this snippet into terminal, even if one error occurs, next commands will be executed, which is not good. \ is for informing shell that command is continued in next line.

Щоб продемонструвати ці роботи, я надаю середовище тестування для цього фрагмента

mkdir -p /tmp/gitcommitToAnyBranch && cd /tmp/gitcommitToAnyBranch &&\
git init 
echo 'this is master file' > file1.txt
echo 'this is file we do not want to have modified in patch branch because it does not     patches any feature' > docs.txt
git add file1.txt && git commit -m "initial commit" 
echo 'now this file gets patched' > file1.txt
git status

Тепер, якщо запустити свій сценарій з параметрами

destBranch=patch
thisBranch=`git rev-parse --abbrev-ref HEAD`
FileToPutToOtherBranch="file1.txt"
message="patched file $FileToPutToOtherBranch"

You will have file1.txt modified only in patch branch, for more see gitk --all

3
додано

Хоча в даний час не існує жодної команди для цього, є щонайменше два інші варіанти.

  1. Ви можете використовувати Gіthub API для створення фіксації. це повідомлення деталі, що створюють копію в github repo.

  2. Створення github-сторінок як підмодуль .

  3. Використовуйте декілька команд сантехніки для створення фіксації.
    Книга git містить опис сантехнічних команд, які використовуються для створення commit

Примітка: команда тепер mktree не mk-tree

3
додано

Я зробив невеликий інструмент, який робить саме це: https://github.com/qwertzguy/git-quick

Це дозволить вам редагувати певні файли з іншої галузі без повної перевірки іншої гілки (просто файли, які потрібно редагувати) і здійснити їх. Все це ніколи не впливає на вашу робочу копію або місце розташування.

За цими сценами він використовує комбінацію гітарного робочого та редкого оформлення. Джерело є досить невеликим, тому ви можете прочитати.

1
додано

Якщо ви випадково змінили речі в неправильному розділі, виконайте кілька простих кроків:

  1. Прийняти ці зміни;
  2. об'єднайте їх у правильну гілку;
  3. Оформити гілку, на якій ви були спочатку, і відновити його раніше,
  4. Очистіть ваші зміни від "git checkout -.".

Після цього треба добре. Ви також можете об'єднати, скинути і очистити свої зміни вибірково.

1
додано

Ось як я це роблю:

якщо я навмисне взяла на себе зобов'язання, поверніться назад на одну програму:

git reset --soft 'HEAD^'

додайте файли, які хочете додати

git add .

створити нову тимчасову гілку:

git checkout -b oops-temp

внесіть зміни:

git commit -m "message about this commit"

Ознайомтесь з відділенням, які ви мали намір перевірити:

git checkout realbranch

злийте стару гілку:

git merge oops-temp

видалити стару гілку:

git branch -D oops-temp
0
додано