CODEWITHSUNDEEP
git
peter cooke
peter cooke

Reputation: 999

git: need to build on one branch and merge that branch to another branch

our builds take a long time. with unit tests about 4 hours. I am trying to build and run unit tests on master. At the same time I need to merge master to branch A.

is there a way to NOT change the what the files look like on the file system and to merge to another branch

---------\-----master
          \----A

something like "git merge from_branch to_branch" or "git merge to_Branch from_Branch" I have observered some posts with alais but those look like they do a "git checkout A; git merge master" which is not what I want to do. Can't do checkout because I have processes needing to access files in master

thanks

Upvotes: 0

Views: 28

Answers (2)

Mykola Gurov
Mykola Gurov

Reputation: 8695

Agree with @Schwern that the easiest solution for this problem is to have a clone of the repository.

Sometimes instead of a full clone you might find copied workdir more convenient. In particular, you don't have to pull/push between these two local git repositories.

The best solution would be a CI server indeed. Intermediary solution on this way could be doing such builds in a docker, provided you can use it and can run your tests on linux.

Upvotes: 2

Schwern
Schwern

Reputation: 164809

Our builds take a long time. with unit tests about 4 hours. I am trying to build and run unit tests on master. At the same time I need to merge master to branch A.

There's a few good practices which will eliminate this problem. First is to not work on master, but exclusively on feature branches. master should only be used for starting new feature branches and integrating already tested feature branches. This very good practice solves a lot of problems.

- B - C - D [master]
           \
            E - F - G [feature]

Use git merge master to keep your feature branch up to date with changes in master (alternatively git rebase master to avoid lots of unnecessary merge points). Feature branches can be safely pushed without endangering other branches.

Second is to use a continuous integration server. That is, have a dedicated machine which does nothing but build and run the full test suite on whatever is pushed to the central repository. This has the advantage of providing an environment as close to the real production environment as possible (not whatever happens to be on your development machine). Travis CI is an example of a CI service, Jenkins is an Open Source installable CI server.

Note that you can run your own CI server on a virtual machine on your own desktop.

With that in place, you no longer need to wait around for long tests to finish. You can safely push your feature branch and the CI server runs the tests. Meanwhile you can do whatever you want with your development copy.

If you don't want to do all that and wish to continue working on master and running long tests on a development machine, the simplest solution is to clone your development copy to a new location to do your testing. Cloning your development copy, not the shared remote copy, means it will have your work and branches.

git clone /path/to/my/devel /path/to/my/tests

Run your tests in /path/to/my/tests and do your development work in /path/to/my/devel.

Upvotes: 1

Related Questions