CODEWITHSUNDEEP
git
John Little
John Little

Reputation: 12435

git, what does pushing one branch to another do?

Use case: We have 5 branches for 5 environments. E.g. main=env1, test=env2, experimental=env5

When we update a branch, it automatically builds and deploys to the corresponding env.

I have some test code which I want to try out on the experimental env5 environment (which I will probably break in the process)

I could checkout the experimental branch, checkout the main branch (where all our production code goes), merge main and experimental (so experimental is up to date and the same as main) branch off experimental, change some stuff, commit my branch, the merge my branch with the experimental branch, then push the experimental branch back to the origin.

This works, but has the big drawback that the next person who uses experimental gets my (probably broken) test code.

I could try to "reset" the experimental branch back to the commit before I started, but this is somewhat beyond my level of expertise.

Some said I might be able to do it this way:

  1. checkout main
  2. pull
  3. git checkout -b my_experiment
  4. do some changes
  5. commit my changes.
  6. git push origin my_experiment:experimental
  7. do some testing.

The crux is what is going on in step 6? how is it merging my changes with the experimental branch, and how would I set it back to say the same as main after (so the next one who uses experimental doesnt get my changes)

== update ==

From the helpful comments below, I think I am missing a step:

To experiment:

  1. git checkout main
  2. git pull
  3. git checkout experimental
  4. git pull
  5. git merge main <== bring experimental branch up to date with the main branch
  6. // now I have the experimental branch up to date.
  7. git checkout -b my_experimental <= this is now a branch of experimental, not main
  8. make some changes.
  9. git commit
  10. git push origin my_experimental:experimental

To revert (so others dont get my code)

  1. git push origin experimental:experimental

Will this work? or do I need "-f" in the pushes?

Upvotes: 0

Views: 148

Answers (2)

Randy Leberknight
Randy Leberknight

Reputation: 1463

If you are worried about other developers pulling the experimental branch while it is pointing to your test-version, you can't really stop that, so I propose a different procedure.

Can you reconfigure you Continuous-Integration system so that branch my-experimental will be deployed to env5?

This way branch "experimental" does not have to be corrupted with your test-changes.

You could have both branches be set up to deploy to env5.

Upvotes: 1

IMSoP
IMSoP

Reputation: 97928

A branch in git is a pointer to a particular commit, and nothing more.

The push command requests a remote server to point a particular branch at a particular commit. It will never perform a merge, that always has to happen locally first. When you specify a branch as the source, that's just a way of specifying a commit: whatever commit your local branch of that name currently points to.

By default, the remote server will reject any push that is not a "fast-forward" - that is, where the new commit being pushed doesn't have the previous branch location in its history. If you specify --force or the slightly safer --force-with-lease, it will completely ignore the current branch location on the remote server, and just make the branch point at whatever commit you ask for.

(The "with lease" means git will check if someone else has changed the remote branch since you last fetched it, so that you always know what you're overwriting.)

So one way too achieve what you're discussing would be this:

# overwrite "experimental" with whatever branch you want to test
git push --force-with-lease origin my_experiment:experimental
# once you've tested, overwrite it again with something else
git push --force-with-lease origin main:experimental

Upvotes: 2

Related Questions