私はWindows 10コンピュータ（Cygwinベース）からROOTおよびPythonスクリプト/マクロにアクセスするための端末としてmobaXtermを使用してきました。また、同僚と私はGitlabを使ってこれらのスクリプト/マクロを共有してきました。最近、私たちはGitlabを使って共有されたLaTeXドキュメントの作業を始めました。私が直面している問題は、LaTeXエディタとして使用するOverleafとGitlabを統合することです。
私は与えられたガイドに従った。OverleafのgitリポジトリをGithubに関連付ける方法は次のとおりです。、ちょうどいくつかの迷惑な問題が発生しました。
まず、次の行を使用してOverleafリポジトリを自分のコンピュータにgit cloneできるようです。git clone https://git.overleaf.com/%%%%%%%%%%%%%% note_name
続いてgit remote rename origin overleaf
それから私は糸を引いた。git pull overleaf master
これらのどれも問題を起こさないようでした。その後、次の行でGitlabリポジトリを追加しました。git remote add gitlab https://gitlab.thing.ty/folder/note_name.git
git config --global push.default matchingその後、Gitlabの予備プッシュを行いました。
git push gitlab
Username for 'https://gitlab.thing.ty':
Password for 'https://[email protected]':
Counting objects: 21, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (21/21), 50.81 KiB | 0 bytes/s, done.
Total 21 (delta 7), reused 0 (delta 0)
To https://gitlab.thing.ty/folder/note_name.git
ccf7614..596ba69 master -> master`
その後、Overleafからインポートします。git pull overleaf master
remote: Counting objects: 5, done
remote: Finding sources: 100% (3/3)
remote: Getting sizes: 100% (4/4)
remote: Compressing objects: 100% (7764/7764)
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://git.overleaf.com/%%%%%%%%%%%%
* branch master -> FETCH_HEAD
f0173f3..d3bb61b master -> overleaf/master
Merge made by the 'recursive' strategy.
Section2.tex | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)`
これで、変更をコミットし、変更をGitlabにプッシュする必要があるときに問題が発生します。次の行が表示されます。
git commit -m "configuring git access, no major edits have been made"
On branch master
Your branch is ahead of 'overleaf/master' by 16 commits.
(use "git push" to publish your local commits)
nothing to commit, working directory clean
そして
git push gitlab
Username for 'https://gitlab.thing.ty':
Password for 'https://[email protected]':
To https://gitlab.thing.ty/folder/note_name.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to
'https://gitlab.thing.ty/folder/note_name.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
2つの異なるストレージを同時に管理する方法がわからないようです。
答え1
コミット数が最も多いリポジトリは、変更を試みる前にプルするリポジトリでなければなりません。
git pull upstream master
次に、gitlabリポジトリがアップストリームと同期していることを確認してください。
git push origin master
これにより、作業中に両方のストレージが同期されます。
git logあなたは次のようなものを見なければなりません
commit 798a0433ad807b6127066cac3f6e33d6551ef0d4 (HEAD -> master, upstream/master, origin/master)
これは、両方のリポジトリが同じコミットにあることを意味します。
完了したら（別のブランチで作業している方が良い）、その変更をコミットする必要があります。git commit --all -m "some text"
これを完了すると、両方をリードする新しいブランチがgit log表示され、upstream使用originする必要がある2つのいずれかに変更を統合したい場合は、リポジトリに1つが作成されますgit rebase。マージ時にすべてのコミットが溶けるのでfast-forward使用しません。pullその後、両方のストレージへの書き込みアクセス権がないとします。
たとえば、git fetchリポジトリから変更をダウンロードしてgit fetch upstream masterコミットを表示し、安全な方法で変更をマージするためにgit log使用されます。git rebase
引用するGit公式書籍詳細については、最初の3章を読んだ後にアイデアを得ることができます。
答え2
複数のgitリモートを使用するには3つの一般的なシナリオがあり、これを処理する方法は必要な項目によって異なります。
- カスタムパッチを含むいくつかのソフトウェアフォークがあります。これは私が知っている最も一般的な状況であり、私が個人的に経験した唯一の状況であり、実際には非常に一般的な開発状況です。良い例は次のとおりです。https://github.com/Ferroin/linux、小規模ローカルパッチコレクションを維持します。https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
- ジョブを公開し、互いに同期を維持したい複数のアップストリームリポジトリがあります。定期的にこれを行うプロジェクトはありませんが、プロジェクトがリポジトリに対して異なるホスティングプロバイダを切り替えるときに時々行われます。
- 別々の開発とリリースのリポジトリがあります。これはケース1と非常によく似ており、逆です。
前述したように、状況を処理する方法は現在の状況によって異なります。最も簡単な場合（私の場合でもあります）考える実際に問題の説明を提供しました。これはケース2です。ここでは、管理者は更新をプッシュするときに両方のリポジトリにプッシュすることを確認します（gitでは明示的に各リモートにプッシュする必要があります）。ケース3も非常に簡単です。バージョンを公開するときは、バージョンにタグを付けて両方のリポジトリにプッシュし、何かを公開しない場合にのみ開発リポジトリにプッシュします。
ケース1は最も一般的ですが、プッシュおよびプルコマンド以上の機能を含むため、最も複雑です。セカンダリリモートが重要な唯一のケースは、アップデートアップストリームがあるときです。この時点でその更新をインポートし、その上にローカルブランチをリベース（またはローカルワークフローに従ってマージ）する必要があります。
また、公式文書を読むことに興味があるかもしれません。子書、これは物事をよく説明する役割を果たします。 「分散Git」に関する章は、おそらくこの質問に最も関連しているでしょう。ただし、ワークフローを理解するには、Gitがソース管理を実行する方法について良い理解が必要なので、記事全体を読むことをお勧めします。