Is git only useful for text files / source code?

Very noob question.

Is it good to use git for my project (like synchronization between different repositories, version control is not the main one), including images, pdf files, Word documents, maybe even some exe files?

How to track changes in pdf files, images, exe files, if at all? If it stores all modified files simply because there is some difference with the HEAD version, the repository can become quite large after several commits .. Or is it still possible to save only incremental changes to files other than text files?

Bottom line: Is git good (or at least acceptable) for synchronizing large projects? For me, this will be enough if it is not worse than Dropbox, etc. (From the point of view of the final result, the GUI is not a problem).

+6
source share
4 answers

Git can see that you have modified your non-text files, but in this case you cannot get the most out of git. With text files, you can see what the actual difference between the various versions / commits is.

With this, you can try this solution for comparing images in git . I am sure there should be software to display the differences between the other types of files that you may need, and this will make them check the differences.

Compared to dropbox, git should be better, because you can use commit messages that say what was done in this particular change, and you can create function branches; but this is a little more complicated due to its purpose, namely tracking source code differences between versions.

EDIT:

and no, ̶ GIT does not save gradual changes for non-text files, ̶ but Dropbox does not, As far as I k̶n̶o̶w̶.̶

It seems that git stores non-text files as character strings, so yes, it should track the differences. Therefore, any good difftool , such as meld or Beyond Compare , should be able to determine the difference between two images, for example. For example, I was able to see the differences between the two png images using Beyond Compare .

It also seems to work well with PDF files, but, like exe files, you should not keep track of these types of files with version control. Instead of PDF s, keep track of their source code - for example, LaTeX files (which are plain text). Due to their nature, compiled files, such as exe files, are not suitable for version control. The reason for this is that even if you are editing directly in the character string of the file, you will not be able to do much - you must edit the source code.

+4
source

Git can be used for large projects, but you should not check the generated files (e.g. pdf, exe, etc.). Add a .gitignore file (Google details) that says which git files should be ignored.

If you want to include Word files (or similar ones), which are binary files but are not generated, you can tell git how to “split” such files. This means that you tell git how it can compare two word files and decide how to merge two different word files. Again, Google will be your fried to find out details on how to do this.

+2
source

Binary files can go into one of the following categories:

  • Binary files that can be played by source code. It makes no sense to store and track them. You usually do not edit the .exe file to make changes. Just remember to save all the building scripts needed to play the assembly, and add the binaries to .gitignore.

  • Binary files that can be edited and compared. For example, office files. There are some workarounds, such as converting them to text, as shown here . Some GIT IDEs may allow an external tool to create diffs.

  • Binary files that can be edited, but difficult to compare. How do you imagine the difference between the two videos? Perhaps, but difficult. Depending on the size, I would add files to GIT. You always get most of the benefits of GIT like tracking different versions, knowing when a single file changed, etc. The price you pay is the larger repository. For comparison, people need to open files anyway.

  • Binary files that are usually not edited and used as inputs. For example, a .jar file as a dependency. In this case, you need metadata about what this binary object is and how to get it. You can try systems like Maven, where you track dependencies that store pom.xml and add binaries to gitignore. Other files can be tracked using the Dependecies.txt file of the manual (this version requires version My.Lib1.jar 10.32.3 ...). You will need the discipline to update the file with every change. This will help you find out where the binary changes are in each version.

+2
source

if you made changes to the file, then git does not save only the change (difference). instead, it saves the entire file again. for example: if you changed one line of a 2 MB file. git will save the whole file again with the new change. (then the repository size will be 4 MB)

+1
source

Source: https://habr.com/ru/post/979036/


All Articles