Unified updates : Update private repo with updates from local files(refactored, renamed, updated) & get regular updates from original repo

Question

I have just started learning to us GitHub CLI tool on Windows. Consider me a newbie I have a use case that looks like this :

Let me summarize before i go a little deep:

My use case is : Cloning an open source project (which updates regularly), i.e create a local copy of it and make modifications(including renaming files and folders), pushing the changes to my private repo but at the same time I require regular updates from the open source project reflected in renamed format. Do i have to rename the files & folder every time the project releases an update and push it to my private repo ?

Lets say Project A is an open source project that regularly updates its files. Project B is my private repo on GitHub. All the initial steps for linking my Project C(local repo) to Origin(Project B) & Upstream(Project A) have been completed through the cli and config file inside .git folder.

On my computer , My local copy Project C has been obtained by using the command

git clone "https:..../project-B.git"

Now my purpose is the following :

1.To make heavy customizations to the code itself in my local copy Project C on my computer and push those changes to my private copy: Project B. This includes but not limited to renaming the project folders and files.

2.To obtain regular updates from Project A and the same needs to be updated in the private repo Project B.

In short, My private repo project B should have my changes and the regular changes that happen from the upstream end: project A

What's the best approach to achieve this?. I'm aware of the following steps to Push my local copy into Private Repo B :

Step 1 : git status -->to check for the changes in local copy.
Step 2 : git add --all
Step 3 : git commit -m 'message reflecting the nature of change'
Step 4 : git push -u origin master
where origin is my Private repo B and master is the branch that contains all the files. 

I'm also aware of pulling in the upstream files by using :

git pull upstream master --> to pull in the latest changes from project A onto project B.

My Question is therefore :

1.When exactly should I Use git pull or git rebase with find renames : Before or after I push the committed changes. My limited understanding is git rebase is to find renamed files in origin(in my use case) and make the changes ?

Or

2.I need an entirely different approach?

Or

3.An approach to the above with minor shifts?

EDIT:

I have successfully pushed my local changes (project C-> project B(private repo on on git) using the command git push -u origin master.

Only, I need to know how can I pull changes from repo Project A(open source which regularly updates) and update my current local copy which is already renamed(folder, files everything else) & other new lines of code that is added. Eventually I need to push those updated changes from Project C(local copy)--->Project B(private repo) and have my private repo UpToDate with latest commits.

EDIT : Taking a public repo docker-jitsi-meet as a repo i need regular updates from and also modified and renamed in my private repo. I have done the following :

1.I Bare cloned the public jitsi-meet repo to my local machine.

2.git clone --bare github.com/jitsi/docker-jitsi-meet.git.

3.cd into my local copy and git push github.com/user/project.git (private repo).

4 Deleted the bare copy and cloned the repo now git clone github.com/user/project.git

5.Add the public upstream repo as a remote: git remote add upstream github.com/jitsi/docker-jitsi-meet.git.

6 git fetch --all shows me lots of changes from upstream which i need to pull in.

7. I use

git merge upstream/master and the following trace is displayed :

$ git merge upstream/master
Auto-merging CHANGELOG.md
Auto-merging docker-compose.yml
CONFLICT (content): Merge conflict in docker-compose.yml
Auto-merging focus/rootfs/defaults/jicofo.conf
CONFLICT (content): Merge conflict in focus/rootfs/defaults/jicofo.conf
CONFLICT (modify/delete): jibri/Dockerfile deleted in HEAD and modified in upstream/master.  Version upstream/master of jibri/Dockerfile left in tree.
CONFLICT (modify/delete): prosody/rootfs/etc/cont-init.d/10-config deleted in HEAD and modified in upstream/master.  Version upstream/master of prosody/rootfs/etc/cont-init.d/10-config left in tree.
Auto-merging web/rootfs/defaults/system-config.js
CONFLICT (content): Merge conflict in web/rootfs/defaults/system-config.js
Auto-merging xmpp/rootfs/defaults/conf.d/jitsi-meet.cfg.lua
CONFLICT (content): Merge conflict in xmpp/rootfs/defaults/conf.d/jitsi-meet.cfg.lua
Automatic merge failed; fix conflicts and then commit the result.

8. I did

git $ git merge upstream/master -X --strategy-option="find-renames=20"

and get the following :

error: Merging is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

Answer 1

The simplest way is usually to add two remotes in your local clone and then continuously merge changes from the secondary remote. A remote is like a bookmark for another repository; when you clone, the origin remote is created automatically for you, which points to the source from which you cloned.

The following commands only need to be taken once:

git clone https://github.com/user/project.git localclone
cd localclone
git remote add upstream https://github.com/upstream/project.git

Then later to "sync" your fork:

git fetch --all
git merge upstream/master
git push origin HEAD

This will merge all changes that have happened in the "main" branch of the "upstream" remote/repository since you last fetched+merged.

Note that if commits in upstream change the same lines as you did in your fork, there will be merge conflicts which you need to resolve.