# How do you develop a package without having to commit, push and pull all your changes all the time

**URL:** https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670
**Category:** New to Julia
**Created:** [July 5, 2017, 7:48pm UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670 "2017-07-05T19:48:59Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Jackels](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@Jackels](https://discourse.julialang.org/u/Jackels)
#### Post date: [July 5, 2017, 7:48pm UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/1 "2017-07-05T19:48:59Z")

</div>

The title is my question. I am always testing my package by `using MyPackage` now according to documentation my LOAD\_PATH is checked after Pkg.dir() is checked, where my old version of MyPackage is. I want a stable version of MyPacke in Pkg.dir() for testing and comparisons. Now whenever I want to test a change to MyPackage I will have to commit my changes, push it to some repo and then pull it again inside `Pkg.dir() */MyPackage ` ( if I feel like wasting even more time I would use `Pkg.update("MyPackage") ` ). I also spam the repo with useless commit messages basically being “debug”.

Now this does not seem like a sane development process to me, what am I doing wrong?

---

<div class="post-metadata">

### Author: ![Michael\_Eastwood](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/michael_eastwood/32/669_2.png) [@Michael\_Eastwood](https://discourse.julialang.org/u/Michael_Eastwood)
#### Post date: [July 5, 2017, 8:07pm UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/2 "2017-07-05T20:07:14Z")

</div>

You could always set `JULIA_PKGDIR` to have two separate package environments.

ie. use `JULIA_PKGDIR=/path/to/development/pkgdir julia` to run julia without touching the stable version in your usual package directory.

---

<div class="post-metadata">

### Author: ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)
#### Post date: [July 5, 2017, 8:07pm UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/3 "2017-07-05T20:07:29Z")

</div>

I had problems to follow, what you actually try to do, but my recommendation would be:

- learn git (especially about branching)
- work for development with a local repository only.

You’ll need local git access (commandline or GUI) and put your stable version into a branch ‘stable’, and Pkg.checkout should enable you to select this branch.  
The remote (any remote) repository you only need to share code. git works locally also.

---

<div class="post-metadata">

### Author: ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)
#### Post date: [July 5, 2017, 8:24pm UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/4 "2017-07-05T20:24:41Z")

</div>

I typically develop in the same directory where I also keep the stable version, using “git checkout” to switch between development and stable branches. But this only works because I never need the stable version at the same time as I am working on a development branch. (In that case I guess setting the `JULIA_PKGDIR` environment variable would be the way to go.)

For tests that take a while to run, or that need a different OS or hardware, I’ve sometimes used git hooks. That way I can push commits to a server and it will run the tests automatically. This leads to lots of “debug” commits, but it is possible to “squash” them, to make the commit history look better.

---

<div class="post-metadata">

### Author: ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [July 6, 2017, 5:53am UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/5 "2017-07-06T05:53:47Z")

</div>

I am not sure I understand what you are doing.

I typically create a local package with `Pkg.generate`, and work from there. If it is production code, I work in branches, but otherwise on the `master`. I only commit changes to keep track of it, and do not necessarily push/pull unless I have a repo on Github.

Learning git is quite useful. Some editors have `git` integration (eg Emacs), which makes working with version control really seamless.

---

<div class="post-metadata">

### Author: ![waldyrious](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/waldyrious/32/80_2.png) [@waldyrious](https://discourse.julialang.org/u/waldyrious)
#### Post date: [July 6, 2017, 9:36am UTC](https://discourse.julialang.org/t/how-do-you-develop-a-package-without-having-to-commit-push-and-pull-all-your-changes-all-the-time/4670/6 "2017-07-06T09:36:00Z")

</div>

Isn’t this exactly the use case for [Revise.jl](https://github.com/timholy/Revise.jl)? If so, you’re in luck @Jackels – it was released just a few days ago 🙂

> [@\[ANN\] Higher productivity (fewer Julia restarts) with Revise.jl](https://discourse.julialang.org/t/ann-higher-productivity-fewer-julia-restarts-with-revise-jl/4564):
>
> I’m announcing a new package that may speed up your development: [https://github.com/timholy/Revise.jl](https://github.com/timholy/Revise.jl). Revise makes it easier to update code and have the changes take effect immediately, without having to restart Julia. Please see the README for more information.
