I do not understand local repo. You have a local clone and several staging which are just different tagged revisions of the remote repo. If there are more than one user you need to keep everything in the remote repo and push/pull frequently. short lived branches etc. but everything lives remotely. Not a single add without an immediate push.
And the remote servers like gitlab/gogs handles conflict by leaving a pull request for the admin to accept/reject, much better than rebasing long lived branches with outdated code :-)
When working with a clone of some remote repository, what you have is a git repository on your local machine that is a copy of the remote at that point in time. All work you do is in your local repository, which, to your point, you should constantly keep in sync with the remote repository.
Also, I agree 100% with not wanting long-lived branches, but rebase and merge (and their differences) are very important concepts to understand in git. You can't
keep everything in the remote repo and push/pull frequently
without doing a merge or rebase at some point, whether implicitly or explicitly. Every pull from remote causes a merge of some sort. All commits, including pull requests (when accepted), have to be merged into your trunk somehow--whether with a merge commit, or by being rebased then merged. The author does a great job of illustrating the distinctions and benefits of both.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I do not understand local repo. You have a local clone and several staging which are just different tagged revisions of the remote repo. If there are more than one user you need to keep everything in the remote repo and push/pull frequently. short lived branches etc. but everything lives remotely. Not a single add without an immediate push.
And the remote servers like gitlab/gogs handles conflict by leaving a pull request for the admin to accept/reject, much better than rebasing long lived branches with outdated code :-)
When working with a clone of some remote repository, what you have is a git repository on your local machine that is a copy of the remote at that point in time. All work you do is in your local repository, which, to your point, you should constantly keep in sync with the remote repository.
Also, I agree 100% with not wanting long-lived branches, but
rebaseandmerge(and their differences) are very important concepts to understand in git. You can'twithout doing a
mergeorrebaseat some point, whether implicitly or explicitly. Every pull from remote causes a merge of some sort. All commits, including pull requests (when accepted), have to be merged into your trunk somehow--whether with a merge commit, or by being rebased then merged. The author does a great job of illustrating the distinctions and benefits of both.