On 12/18/21 2:49 PM Greg Ercolano wrote:
>
> So if you're working on a branch, and occassionally want to keep up with
> current development on origin/master to continue working, what's the
> best way to sync up?
>
> I believe albrecht said this one command would do the job
> if you run into trouble pushing a branch:
>
> git pull --rebase
>
This is correct if you want to sync the branch you're working on with
the remote repository where someone else (or even you, e.g. from another
system) may have pushed branches to.
This is often the case with FLTK development in the main branch if the
remote branch (e.g. origin/master) got pushes while you were working
with your local copy of 'master' and committed in master. This can also
be the case after you merged your development branch into master.
Assume remote/master got a commit from Manolo, say commit A.
You were working on your local master and committed B. Now you can't
push because Git(Hub) tells you that the branches have diverged and you
should 'git pull'. As I wrote you shouldn't do this because it would
merge the remote branchThe situation is:
remote: origin/master - A
local: master - B
after git pull --rebase:
remote: origin/master - A
local: master - A - B'
Note that I wrote B' because this is formally another commit than B
because it was rebased (it has another hash).
Now it is safe to `git push' because it would append your commit B' to
the remote commit A. The new situation after `git push' is:
remote: origin/master - A - B'
local: master - A - B'
which is what you want.
Now, after you rebased your local branch and everything looks fine you
try to push again. It can happen that git tells you again that your
local and the remote branch diverged. What's going on? Well, someone
else pushed commit C in the meantime. Don't worry, just go back to `git
pull --rebase' and try again...
> Is that also sufficient to keep an "in progress" branch synced with
> origin/master?
> The net seems to recommend the following for resync'ing an in progress
> branch:
>
> git checkout master -- switch from your branch to master
> git pull -- get the latest from the remote. If
> your local master is clean, this shouldn't fail
> git checkout <local-branch> -- switch back to your branch
> git rebase master -- rebase your branch to master
>
> ..or is that pretty much the same thing that 'git pull --rebase' does
> while you're
> on your branch?
>
It's different because you want to "move your local branch forward on
top of another branch". I'm calling your local branch "working" in the
following graphs (use a fixed font if the HTML mail I'm sending doesn't
do this for you):
Current situation:
remote: origin/master - A - B - C - D
local: master - A
\
local: working . . . . E - F - G
What you want to achieve is that your commits E - F - G are "rebased"
onto the tip of remote branch origin/master after commit D, like this:
remote: origin/master - A - B - C - D
local: master - A - B - C - D
\
local: working . . . . . . . . . . E' - F' - G'
The recipe above does exactly that (replace "<local-branch>") with
"working". Again, commits E' - F' - G' differ from your original E - F -
G in that they have different hashes.
Note: although Git is good at doing such things it can happen that you
need to resolve merge conflicts when doing a rebase. Then it is obvious
that you should test your updated branch and/or verify with tools like
`gitk' that your commits and the result of the merge are consistent and
what you wanted to do.
However, even if Git does not flag merge conflicts it is still possible
that merging two branches (or rebasing one on top of another one) may
introduce bugs. A simple example is if two changes to fix a bug in
different places of the code merge silently but create another bug
(think of adding 1 in two different places of the code which git does
not notice as a conflict).
Hint for advanced git users: the commands can be "simplified" if you
remember the correct syntax (be careful not to flip arguments). Assume
your local branch is "working":
-- (on branch working)
git checkout master -- switch from your branch (working) to
master
git pull -- get the latest from the remote. If
your local master is clean, this shouldn't fail
git rebase master working -- rebase your branch 'working' on
'master' and checkout 'working'