1
I would like to do a test in Git doing the versioning of any Word document for example:
- Type any line and commit
- Type another line and commit
- Go back from version 2 to version 1 and check the word document if it is as in the first step.
1
I would like to do a test in Git doing the versioning of any Word document for example:
1
I’ll make an example for you to understand:
git init
Initialized Empty Git Repository in [
caminho da pasta
]/.git/
git status
On branch master
No commits yet
Untracked files: (use "git add ..." to include in what will be Committed)
documento-word-2013.docx ~$cumento-word-2013.docx
Nothing Added to commit but untracked files present (use "git add" to track)
git add .
git commit -m "Documento criado"
git add .
git commit -m "Adicionado segundo texto lorem"
git log
commit 97ccced5fc1f03bf8a4c1747be6915039f384c9c (HEAD -> master)
Author: lipespry
Date: Thu Jan 10 04:59:49 2019 -0200
Adicionado segundo texto lorem
commit 2e5e1914988c4aab4d83e57aa0b59254da4fbe18
Author: lipespry
Date: Thu Jan 10 04:58:12 2019 -0200
Documento criado
git checkout 2e5e1914988c4aab4d83e57aa0b59254da4fbe18
Note: checking out '2e5e1914988c4aab4d83e57aa0b59254da4fbe18'.
You are in 'Detached HEAD' state. You can look Around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by Performing Another checkout.
If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command Again. Example:
git checkout -b <new-branch-name>
HEAD is now at 2e5e191 Document created
@Edit (thanks to Jefferson Quesado):
It’s a shame, but the Git does not detail the changes in the Word (git diff
). At least not natively.
If there is no quality and no effort, the ideal would be to comment you do not think? It would be better not to have put this paragraph.
@Noobsaibot Until it’s not a bad idea. Done! ;)
Just one question: when making a change and saving the document, what the git diff
accuses?
@Lipespry perfect. It’s just that if the docx format is textual, git will work well with it. Now, if it’s a large binary blob, it will turn into a mess in the internal parts by my recollection. Git works great with textual versioning
@Lipespry edits the file and saves, or tries to see the git log 2e5e191
Not even Github can do it defame the changes. See this commit... In the git log
does not show exactly the changes. Only the commit message and basic information like author, date, time, etc...
"Binary file not Shown"... is, there will be some mess with git compression...
I believe that, instead of the mess, there is no direct compaction... You’ll know, right?! kk
Thanks @Lipespry, helped a lot.
@Laurobrizidio For nothing! In fact, the community recommends that when solving your problem, accept the answer as such.
The most important - which is to ignore the temporary files that Word creates when a user opens the file - was not put in the answer. The most common problem of who versioning word files and persisting temporary, causing endless conflicts...
including, I realized now, the answer includes a temporary commit. OP will be frustrated when it sees the amount of problems caused...
@Leonardoalvesmachado I never versioned Word file. But I have already versioned other files and formulated my answer based on such. As for the temporary files, I think they are created when opening the file and are deleted as soon as the job ends (when you close the word). I don’t see this as a danger to versioning. How about formulating a response relating your experience? It will be of great use to curious future.
@Leonardoalvesmachado justly. When I circled git status
Word was open. I closed it and the file did not enter the versioning. Another issue: In the example, although I did with the word open, I added all the files. So if in the future he checks out, he will "restore" both files. It would be redundant...
Exactly @Lipespry - and in your example, you committed with the open file, persisted a temporary binary that will be downloaded by another user, this will invariably cause insoluble conflicts when there is more than one user using the same Word file. So I think it’s important to also teach the use of .gitignore
to ignore such files
In this case, it is recommended to use a compatible versioning tool. Group editing in the same file, even more in word, is not pro git thing...
Browser other questions tagged git versioning
You are not signed in. Login or sign up in order to post.
Talk to me, Lauro! I’ll give you a hint: in your next questions, remember to report your searches, mention your attempts, demonstrate effort and specify exactly where you didn’t understand/manage to do it. This time I answered because it is a simple thing and I understood its objective in the statement. But do not forget to consider for the next! ;)
– LipESprY