However, git will give us the option to stage more hunks which is useful when we make similar changes to different parts of the codebase. Then all we have to do is type y to stage that hunk. table class have been selected, which is precisely what we wanted. Now we can see that only the changes on the. In this case, our two changes that we’ve made are currently part of the same hunk, so we’ll need to split them by typing s. This will list all of the commands for us: What we see here is one part of the codebase, or one hunk, but to see what all these commands mean we can just type ?. We’ve made two changes on two separate elements, but there are all sorts of commands that we can run on something called a “hunk”. Once we run that command we should see something like this: It’s a thoroughly helpful flag that lets us split parts of a file so that we can stage and commit each part separately. Well, it’s going to be very difficult to understand the history of our commits if we run git log. For one, what happens if you changed more than one thing in `styles.css`? Perhaps we changed the borders of an element and then we changed the background color of an element that’s completely unrelated to the first. I’ve been doing this for a long time, but there’s lots of problems with this approach. …and then we’d want to make a commit with that staged code: git commit -m 'Fixed the CSS' You might do something like this: git add styles.css Let’s say we’ve just changed some CSS in a file and we want to stage it with Git.

Gitx vs sourcetree