18

I'm new to version control so please excuse if this question is very basic.

From my understanding GIT is a code version control. we develop a lot of windows applications whose final releases are either .exe or .dll files.

my question is simple how does one handle the final releases of the exe's and dll's? do we use the git repository and keep the .exe/.dll files with the source code when we make a release? or git is not the right tool to manage the versions of the final .exe/.dll files and do we need something else?

how do other organizations handle this? if we need some other application for this what is a simple workflow to handle code version control and final releases of these applications?

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
asif-007
  • 327
  • 1
  • 3
  • 10
  • 5
    See [Storing generated files in Git](http://stackoverflow.com/q/5632280/11343) – CharlesB Oct 04 '11 at 07:14
  • 1
    @CharlesB good and very relevant link. Thanks – asif-007 Oct 04 '11 at 08:30
  • 2
    Just discovered that on my Windows machine I have also have a _global_ Git ignore file inside "C:\Users\MyUser\Documents\gitignore_global.txt" which kept DLLs and EXEs from appearing to be added to a repository. Commented those out and they appear. – Uwe Keim Jun 07 '13 at 05:48

4 Answers4

11

You could keep them stored in git. But I would not put them in the same repository as your source code. You want that repository to be fast. You could link the exe/dll repository to the source one via submodules and that would tie them together. (Good point in the comments below about this)

I usually don't bother "versioning" them like that but keep a back up of all artifacts produced that made it to production.

Some like to use git as the delivery mechanism to move DLLs and EXEs to production.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 6
    If going with the submodules, I'd suggest making the source repository a submodule of the binary, not the other way 'round. For two reasons; the developers only need the sources and you much more often need to find sources corresponding to given binaries than the other way around. – Jan Hudec Oct 04 '11 at 08:16
  • 3
    Good point. You could even have your continuous integration set up do that for you automatically. – Adam Dymitruk Oct 04 '11 at 08:19
  • 2
    Thanks guys for all the help, Jan Hudec makes a very important point. I'll go with this solution :) – asif-007 Oct 04 '11 at 08:29
3

No, version control software isn't normally used to manage binaries. Don't do it unless you're using external libraries or the like in your project. Release binaries are usually archived elsewhere (and backed up).

Technically, the source code in the version control is tagged every time a major or a patch release is made. If in the event the archived binaries are lost, you can always go back to this state and re-create the binaries by recompiling.

jman
  • 11,334
  • 5
  • 39
  • 61
  • 4
    Version control system is perfectly suitable to store released binaries, backups and all kind of other stuff. Yes, it has many tools that are only useful for source code control, but that does not preclude use as archival tool. – Jan Hudec Oct 04 '11 at 08:13
2

You may want to try Git LFS.

Instead of committing binary files you just keep pointers to them. And repository itself stays lightweight.

There are few additional steps for using Git LFS:

  • Download and install git lfs plugin. Make sure git-lfs.exe is in your path.
  • git lfs install in the project directory to update push pre-hook.
  • git lfs track "*.dll"

And that's it. Now all of your dll files will be stored in Git LFS.

More info: https://git-lfs.github.com/

Roman Pushkin
  • 5,639
  • 3
  • 40
  • 58
-1

I am late to the party but I had the same issue. I wanted to keep my build so that I could be getting it from git to my deployment server.

Open your terminal/cmd and run the command below. Locate the gitignore_global.txt file and then comment out .dll. You will see that all your .dll files will start being tracked

git config --list --show-origin
james simbi
  • 26
  • 5