CODEWITHSUNDEEP
gitgit-branchgit-mergegit-pushgit-pull
Roman
Roman

Reputation: 131218

How to work with a remote repository containing many branches?

Let us assume that a remote (central) repository has several branches and in the beginning I have locally the exact copy of the remote repository.

Now I want to change something in one of the branches on the remote repository. I could do some changes to the local copy of the remote branch and then try to push it but I guess that in this case I can have a merge-conflict that will be hard to resolve. So, I guess that one need to do the following:

  1. Create a local copy (branch C) of the local copy (branch B) of the remote branch (branch A).
  2. Do changes to this "copy of the copy" (branch C).
  3. Pull the remote branch again (branch A). It will update the local copy of the remote repository (branch B).
  4. Merge locally the "copy of the copy" (branch C, containing your changes) into the the (updated) local copy (branch B) of the remote repository (branch A, containing changes done by others).
  5. Now you can push the local copy of the remote repository (branch B) (containing your changes and changes of others) to the remote branch (A).

I guess that my description might be confusing. So, I try to summarize it with different words: Copy A into B, copy B into C, modify C, update B using the new state of A (basically copy A into B again), merge C into B, push B into A.

Is it the way to go?

Upvotes: 0

Views: 45

Answers (2)

kabanus
kabanus

Reputation: 25980

What you describe is standard development practice - the local and remote branches are usually on the same commit (a and b in your case), with development done on a third branch C.

Before pushing to the remote you pull, and then rebase (this is generally preferred to a merge) C on top of the result and push back.

This is the safest option IMO, and good practice.

Upvotes: 1

Tim Biegeleisen
Tim Biegeleisen

Reputation: 522074

One very common workflow in Git for working with a shared branch (i.e. a branch which several engineers may be modifying at the same/almost the same time) is the following:

git pull origin the_branch
# work work work
git push origin the_branch

As you correctly pointed out, you might hit a problem when you go to push, because at the moment you push, other folks may themselves have already pushed other commits on top of the_branch. There are two basic approaches at your fingertips here. First, you could pull merge the remote the_branch into your local branch, and then push out:

git pull origin the_branch
# possibly resolve merge conflicts, then make a merge commit
git push origin the_branch

This approach would create a merge commit in your local branch, and that commit might typically therefore appear as part of the history of the remote branch as well. If you don't like merge commits, then rebasing is another option here:

git pull --rebase origin the_branch
# again, possibly resolve merge conflicts
git push origin the_branch

If you go the rebase option, then you would be laying your commits down directly on the top of the remote branch, as if your local branch already had the commits recently made by other people.

There is a lingering edge case with either approach. What happens if new material comes in between the time your merge/rebase and the time you go to push. If that were to happen, then you'd have to merge/rebase again. But in my experience, this almost never happens, and actually I can't even remember this happening to me once.

Upvotes: 1

Related Questions