0

I'm trying to understand git. One thing I keep seeing mentioned is the idea of "partial commits", where instead of staging all changed files and committing once, you stage groups of related changed files separately and make more strategic, smaller-scope commits so that tracing project changes in the commit history is easier. So, the conceptual question I have is this: is the choice of which smaller-scope commit to make first a big deal? Like, if you've chosen to make 3 "partial commits" instead of 1 all-encompassing commit, how important is the decision of the order in which you make those "partial commits"? And why/why not is that order important?

My current understanding, which is likely flawed, is that we can step backwards through the commit history and couldn't "keep" changes from the 1st and 3rd of the mentioned partial commits while discarding those of the 2nd. Hence my question about the importance of the order of commits in a project, especially when dealing with "partial commits." Is the scenario I just described even a realistic/valid one, or am I just making up problems without having experience?

Just trying to understand git more as I read the docs, thank you.

blaughli
  • 161
  • 2
  • 3
  • 11
  • Just commit more frequently as checkpoints along the way, rather than doing a ton of work and then trying to figure out how to logically separate your changes. If it compiles and the unit tests pass, commit it! Then move on. – Daniel Mann Mar 29 '23 at 18:28
  • Just a note about terminology here, "partial" commits isn't really a valid concept. In the scenario you described I would use the wording "small" commits, as opposed to 1 larger commit. So your question becomes something like, "When breaking up 1 commit into multiple smaller commits, does the order of those commits matter?" The answer is going to be "it depends", but ideally, you should strive to achieve it such that any commit could be checked out and built properly. – TTT Mar 29 '23 at 19:19
  • The most important *practical* thing to keep in mind is that it is better to make a lot of small commits and then later combine them as opposed to making larger commits that you might need to split later. The reason for that is that combining commits is easier than splitting them. – Guildenstern Mar 29 '23 at 19:39

2 Answers2

1

How to

If you definition of "partial commits" simply is to not commit all the files at once, that is what the staging area is for.
You add the files you want in the commit to the staging area with git add [<pathspec>...].
Furthermore you can choose to not commit all changes you have in a single file by using the --patch argument.
You can read more on the documentation page

Note that it is best practice if all individual commits can compile.

As for why

It is easier to track down bugs and if needed remove all relevant changes which caused the bug.
It is very hard to see which other parts of the code you need to focus on if the bug was part of a commit with 1000+ lines of changes. It makes tools like git blame and git bisect more useful.

For more reasons to why, you could look into "atomic git commits".

Kim
  • 397
  • 1
  • 10
-1

First, you need to remember where Git is coming from. From Linus Torvalds (video), which needed a way to organize the many patches he received for the Linux kernel.

Selecting the bits (from said patches) in order to create commits, and being able to re-order those commits in order to push a coherent story, was crucial for his workflow.

That is why you have the notion of "staging area" and to "stage" files in order to prepare the next commit.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250