# Standard Git structure and update workflow for simple unregistered packages

**URL:** <https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972>\
**Category:** New to Julia\
**Tags:** compathelper\
**Created:** [May 11, 2021, 6:26pm UTC](https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972 "2021-05-11T18:26:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [May 11, 2021, 6:26pm UTC](https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972/1 "2021-05-11T18:26:49Z")

</div>

I have a package hosted on Github that I work on in VSCode (both of which I am new to). It currently has `master`, `feature-x`, and `bugfix-x` branches that I created as well as some branches from `CompatHelper`. All branches get merged into `master` once they are finished.

However, I noticed a workflow issue when trying to update my package dependencies. How can I test new versions of my package dependencies with my package before adding them to the `compat` list in the `master` `Project.toml`? The `Project.toml` has to be updated before `] update` will work, but then my package says it is compatible with dependent packages before I know if that is true.

I imagine I need to add a new intermediate `dev` branch to my Git structure, but I don’t know how to change CompatHelper so it points to a different branch. Also, complicating my Git tree sounds like a bad idea. I already almost always screw up my merges and end up manually copy and pasting into a new commit for `master` instead. 😩

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [May 11, 2021, 6:37pm UTC](https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972/2 "2021-05-11T18:37:26Z")

</div>

You probably don’t need a `dev` branch. What you need is:

1. Github actions to automatically run tests (including downloading the relevant package versions as specified in your `Project.toml`) on every PR _you_ make
2. Some magic to make sure those tests are also run on every PR that `CompatHelper` makes

This thread: [Easy workflow file for setting up GitHub Actions CI for your Julia package](https://discourse.julialang.org/t/easy-workflow-file-for-setting-up-github-actions-ci-for-your-julia-package/49765) has info for step (1), and these docs: [Home · CompatHelper.jl](https://juliaregistries.github.io/CompatHelper.jl/dev/#Installation,-step-2:-Set-up-the-SSH-deploy-key) have info for step (2).

Once you do this, you’ll get a nice green checkmark on your PRs that verifies that they install and test correctly _before_ merging into `master`.

> [@Nathan\_Boyer](#):
>
> I already almost always screw up my merges and end up manually copy and pasting into a new commit for `master` instead.

I’d definitely recommend asking for help when you get into this state. Git can be confusing, but this isn’t the way 🙂

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [May 11, 2021, 7:20pm UTC](https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972/3 "2021-05-11T19:20:16Z")

</div>

That makes sense. Unfortunately, my package is not open source at the moment, so Github actions is out.

I suppose the manual alternative is to

1. `git checkout` `CompatHelper` branch
2. `] update` on that branch
3. run tests on that branch
4. merge PR
5. repeat

or maybe

1. create a new `bugfix-compat` branch with all the dependency updates added together manually
2. update packages and test on that branch
3. merge into `master`
4. delete `CompatHelper` PRs.

> [@rdeits](#):
>
> I’d definitely recommend asking for help when you get into this state. Git can be confusing, but this isn’t the way

I find it hard to ask for help when I’m in that state, because I don’t know how to describe what is wrong. I usually think I know what to do, but then get an error that says I need to resolve some conflict before continuing and can’t figure out how. One example is [here](https://stackoverflow.com/questions/64395814/how-to-resolve-branch-conflicts-in-vscode-github-pull-requests-and-issues-extens/67378107#67378107). The answer got me halfway fixed, but I still had to undo a previous PR and make some empty commits to `master` before everything started working again.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [May 11, 2021, 7:53pm UTC](https://discourse.julialang.org/t/standard-git-structure-and-update-workflow-for-simple-unregistered-packages/60972/4 "2021-05-11T19:53:58Z")

</div>

> [@Nathan\_Boyer](#):
>
> I suppose the manual alternative is to
> 
> 1. `git checkout` `CompatHelper` branch
> 2. `] update` on that branch
> 3. run tests on that branch
> 4. merge PR
> 5. repeat

That will mostly work, but by testing the `CompatHelper` branch, you’ll miss out on any potential interactions between more recent changes on `master` and that branch. To be safe, I’d suggest:

1. Checkout `compathelper` branch
2. Merge `master` _into_ that branch: `git merge origin/master`

- This doesn’t change `master` (yet). Instead, it brings in any new changes from `master` and unifies them with whatever changes are on the compathelper branch.

1. Resolve any conflicts during this merge. It looks like you’re using VSCode for this–I don’t know how to use that particular tool, but I strongly recommend checking out [https://meldmerge.org/](https://meldmerge.org/) if you want to try something else (I use it constantly and have found it to work well even for extremely thorny merge conflicts in my daily work)
2. At this point, you now have a branch which (a) includes the `CompatHelper` changes, (b) also includes any new changes from `master` and (c) will definitely merge cleanly into `master` when you’re ready.
3. `pkg> update` and `test` as you said
4. merge the PR, which should have no conflicts with `master`