Git related question


I used to use Visual SourceSafe (...yeah I know...) and relatively new to Git. I have to admit I have a hard time wrapping my head around it and many things are not clear. I checked out the "Pro Git" book and watched videos on Youtube, but it's still confusing in many parts and things throw me off because I'm still thinking in the VS way. I understand (hopefully) that VS stores information per file and Git per project.

So let's say I have two files, A and B in the same project. For this example, fileA contains, say, information about the management, and fileB contains information about products.

Someone requests to add the new management people to file A. And another person request to add new products to file B.

If I want to do a commit, I can only write a single description for the commit. But these two updates are totally unrelated, so I don't want to write a single description for both files. I want to do two separate descriptions. FileA: Added Joe Sixpack to management. FileB: Added super hair removal product using yellow bottle image.

I assume in this case I have to do two separate commits? If so, what happens if I have to update 10 files (unrelated) but at the same time. Do I have to commit them separately so I can have separate descriptions?

Also, what happens if I commit fileA: Added Joe Sixpack to management. Then I commit fileB (with it's own description) BUT I specify to ammend to previous commit. In this case what happens to the description? Will both file (A & B) have the same descriptions? Eg, the two descriptions will be merged together? Or what is the scenario?

I realize it's a Git question and not PS, but since PS can use Git maybe someone would know the secret souce?


Comment actions Permalink

The thing to remember here is not that Git stores information per project, but that it stores information per change (commit) in the project repository.

Commit messages are attached to the commit (which can include one or more files) rather than the files.
If you are given requests by two separate people for two different changes, then you need to perform each change and commit them separately. So in your first example, you make the change to fileA and commit that with the description of the change. You then make the change to fileB and commit that with its own message:

Commit 1 (contains only changes related to Joe Sixpack being a new manager):
FileA: Added Joe Sixpack to management.

Commit 2 (contains only changes related to the super hair removal product listing):
FileB: Added super hair removal product listing using yellow bottle image.

If you have 10 files with unrelated changes, then that's 10 commits. It's only when the changes to multiple files are related that you should commit them all together with a single message. In addition, if you have two unrelated changes to a single file, they should also be committed separately. For example:

Commit 3 (removed the yellow bottle image and added a blue one):
FileB: Replaced super hair removal product listing using yellow bottle image with blue bottle image.

Commit 4:
FileB: Removed hair restorer 5000 from product listing.

When amending a commit, you're effectively modifying a previous commit, the original commit message is brought into the commit dialog and can itself be amended. The end result is that both files will have the same message. But for the scenario you've mentioned, this is not really what you want to do. I only use it if I've made another change that belongs to the previous change set, or when I forgot to add something.

If you're wondering about how to manage priority changes that come in while working on an older change, all I can say is: don't be shy with branches :) .

Comment actions Permalink

Hey Simon, thanks for the really good and clear explanations! This helped clear up a few things. I feel the "Pro Git" book (and similar) explain things too "scientifically".

As far as branches go, phew...I haven't even gone near them. That's for another chapter for some other time :-)


Please sign in to leave a comment.