Newbie open-source contributor here.
I forked the TortoiseGit repository on GitLab, then cloned it on my computer, edited one file, and committed to branch master.
A few days have passed and I want to update my local working copy with the latest changes from upstream, before pushing to my remote fork and opening a merge request (and of course doing more development/testing etc).
I added a remote called upstream to my repo and now I'm not sure what would be the recommended action:
git pull from upstream/master to my checked-out branch mastergit pull --rebase //git fetch followed by git rebase.These are the approaches I found during my research. Unfortunately I could not find a comprehensive review of each, nor a recommendation as to which one is typical practice when working in projects from GitHub, GitLab or even those like the Linux kernel.
I tried methods 1 and 3. Method 1 (pull) generates a merge commit (--ff-only is not possible) and my history is, in a way, polluted. It also creates conflicts. Method 3 (rebase) does neither, but I'm not sure how rebase behaves after commits are pushed to remote and so I'm afraid it might cause problems going forward.
So there's my question.
Thank you.
TortoiseGit team member here.
I added a remote called upstream to my repo and now I'm not sure what would be the recommended action:
1. git pull from upstream/master to my checked-out branch master
2. git pull --rebase //
3. git fetch followed by git rebase.
Different team uses different workflow.
See Pro Git (v2) - 5.1 Distributed Git - Distributed Workflows
In TortoiseGit team, we prefer keep the history simple, and contributor usually has the responsibility for resolving the conflicts while rebasing.
So, most of the time, we use "git fetch followed by git rebase", especially when contributing. Then, as you said, creating pull/merge request (by using git push), or updating the pull/merge request (by using git push with force) on GitHub/GitLab.
See How Can I Contribute? and HowToContribute.txt for other detail information.