Wrong step in 1.2: Git workflow

[jeffhuys]

You have a step "Make Changes." (here), where you say this:

---

git add
git commit -a

Why:

git commit -a will start an editor which lets you separate the subject from the body. Read more about it in section 1.3.

---

However, this will not work. When someone runs git add, it will output the following:

➔ git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?

Also, git commit -a does NOT mean "start an editor". It means the following (straight from man git-commit):

-a, --all
           Tell the command to automatically stage files that have been
           modified and deleted, but new files you have not told Git about
           are not affected.

If you want, I can make some changes to this and shoot you a PR. 😄

[elamperti]

@jeffhuys is correct; the git add won't do anything alone, but git commit -a will add all changed files to stage, which is something I advice against strongly because developers frequently end up adding unrelated changes in their commits. Moreover, with just git commit you will bring up an editor to write the commit description. Short commit messages may be added from CLI with -m:

git commit -m "Commit with a short description"

[vpanjganj]

Nice one, @jeffhuys I really appreciate a PR of you have time 😊

[piotrgajow]

Hi,

I have created a pull request with using git add -p and regular git commit.
Using -p --patch prevents adding unrelated changes and helps with splitting changes into multiple commits.

Please let me know what do you think about it :)

[elamperti]

@piotrgajow I'm curious about the idea of instructing new users to use -p when usually there are less time-consuming ways of commiting (you may check what changed before commiting with git diff (or git diff --staged if necessary), or git show after you commited).

That said, I often see developers commiting strange changes (automatic linting or space/tabs conversions, etc) and it will be good if they pay more attention to what's happening with the code, but some of that is covered in 7.2 (Enforcing code style standards).

Another thing to consider with --patch is that if the user doesn't add all changes, there will be changed files and the repository won't be clean, so making a pull or a checkout of other branch afterwards -for example- will fail because there are uncommited changes.

[piotrgajow]

@elamperti git diff will show all of the changes in single scrollable view, whereas -p will present them one by one, which for me is easier to process - divide and conquer. Using --patch also enables the programmer to edit a block of code on the fly (e.g. remove some left out debug console print). I agree that this method is more time-consuming, but I think that it results in cleaner commits what is quite important.

As for the respository not being clean - that is true. However, this is the also a problem for any other method that does not commit all changes. And as you mentioned it is usually not a good idea to use add --all.

It might be to complicated for beginners, but I found using --patch very helpfull, so maybe just add this method as a tip? 😄

[vpanjganj]

@elamperti, yes I suggest you mention this as a tip or preference rather than instruction.

[piotrgajow]

I will update my pull request when I have access to my computer.