# Questions on setting up gitlab/github?

**URL:** <https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958>\
**Category:** Ignition\
**Tags:** ignition80\
**Created:** [April 15, 2020, 4:46pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958 "2020-04-15T16:46:04Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [April 15, 2020, 4:46pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/1 "2020-04-15T16:46:04Z")

</div>

I’m going off the “Best Practices” PDF for Ignition and am trying to set up Gitlab. The first thing I noticed was that there is no GitLab for windows, which is unfortunate as my application runs on a Windows Server 2012. I also see that GitLab needs 4 gigs of ram to run.

Is is there a document for setting up GitLab on windows for Ignition? It’s unclear to me how I would set this up. I have a Dev server running in a VM and a production server running in another VM, both Windows Server 2012 OS.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 15, 2020, 4:55pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/2 "2020-04-15T16:55:15Z")

</div>

You could try a Linux VM, or installing Docker for Windows; there’s an official Gitlab Docker image: [https://hub.docker.com/r/gitlab/gitlab-ce](https://hub.docker.com/r/gitlab/gitlab-ce).

Do you actually specific need Gitlab? There’s lots of web frontends available for `git`, including totally free options with better cross platform support: [https://gitea.io/en-us/](https://gitea.io/en-us/)

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [April 15, 2020, 5:32pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/3 "2020-04-15T17:32:38Z")

</div>

I don’t really care that it is gitlab specifically.

All I really care about is that I could use git to watch for changes that I can track, etc, and then push to my production repo when I am done developing them. gitea seems like it might be the way to go.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 15, 2020, 5:42pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/4 "2020-04-15T17:42:40Z")

</div>

I mean, if you just need to push changes to another repository, you don’t even actually need a web frontend; `git` can do that directly:  
[https://git-scm.com/docs/git-push#URLS](https://git-scm.com/docs/git-push#URLS)  
[https://git-scm.com/docs/git-push#REMOTES](https://git-scm.com/docs/git-push#REMOTES)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 15, 2020, 6:51pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/5 "2020-04-15T18:51:05Z")

</div>

> [@paul-griffith](#):
>
> `git` can do that directly

Yup. I use no web front-end at all. I have a 'git' user on one of my office linux VMs, with SSH keys from each employee (all two of us). The push/fetch/pull URLs are then `git@myserver.example.com:reponame`.

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [April 15, 2020, 6:55pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/6 "2020-04-15T18:55:45Z")

</div>

I don’t suppose there’s any plans for an Inductive Univeristy video on this. I’m still kind of confused. I’m used to using Github, pulling from the master, making a branch, making a push request, getting it code reviewed and then it gets accepted into the master branch.

Now I have a VM for my development server that I need pull, make a branch, submit to, and then from there, push those same fully finished changes to my production server which is also being tracked by Git? I don’t get the work flow or the interaction here to be honest.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 15, 2020, 7:39pm UTC](https://forum.inductiveautomation.com/t/questions-on-setting-up-gitlab-github/33958/7 "2020-04-15T19:39:28Z")

</div>

Pull requests, change requests, etc, that are reviewed in web frontends are not actually part of `git` itself - they’re a layer above, added by external tools because it’s useful when collaborating. But if all you want to do is keep your local dev environment in sync with some remote environment, you can use `git` directly to do so - `git push` can go directly from one computer to another, via SSH or a couple other mechanisms.

If you _do_ need external collaborators/review of your changes, then tools like Github/Gitlab/Gitea are the _easiest_ option; but by no means the only one.
