9

I've used Mercurial before but plan on switching to Git in the near future.

All of the tutorials I've seen that explain how Git works show that files are added to the stage ('git add') before each commit, regardless of whether they have been tracked before.

Mercurial also has a command that works in a similar way ('hg add'), but from what I remember, you only need to do 'add' once. For example, the steps for a new repository look something like this:

hg init hg add . hg commit "Initial commit" hg push

Is this workflow possible with Git and if it isn't, what's the reason for the repeated 'git add'? Just seems unnecessary.

Improve this question
2
  • Note that git add doesn't necessarily add a file, it adds new content that isn't present in the most recent commit. In the case of a new file, the file is implicitly empty in the most recent commit. Commented Feb 18, 2013 at 21:39
  • Using git add moves the files from the working directory to the staging index, whether it is a new file or a modified file. Commented Nov 11, 2017 at 14:56

4 Answers 4

Reset to default
9

The two stage process in git is very powerful. Especially, when editing source code, you often make several changes in parallel that are not directly related.

With the staging area, you can select which files you want to commit and thus create one commit per logical change.

If you want to commit all changes files at once you can use git commit -a as a shortcut.
This stages all changed and deleted files and commits them.
Please note: It doesn't automatically add untracked files. You still have to do that beforehand.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Yep. As @dpkp said the same workflow should work without a problem. I tend to work in 'modes' and don't do that much work on files in parallel, but I can see how that would be useful.
6

Yes, the same general workflow can apply, but the "add" command can also be used more selectively, by adding only certain files or only certain portions of files to each commit. This makes it easier to separate logically different patches into different commits, which makes it easier to track and share with others.

But yes, you can just "git add ." and everything will go into the staging area for commit. As mentioned in another answer, "git commit -a" is a partial shortcut (it won't add new files, but will commit all changes/deletes to already tracked files). Try "git status" to see what will be included in your next commit and what won't.

UPDATE I should also note that the complement to git add is "git reset HEAD ", which removes the file from the staging area for your next commit. Also, if you are interested in separating edits within a single file into multiple commits, use the "-p" flag to both git add and git reset in order to step through the file interactively and choose which chunks to add/reset.

Improve this answer

2 Comments

That's what I figured, but the documentation and seeing people actually use Git doesn't make that point as clear as it probably should be. Personally, I'm more likely to commit frequently as I finish working on individual tasks or features. Having seen Fog Creek teach DVCS, it's clear that because you have a complete copy of the code, "commit" is a relatively safe operation since it only affects you. As long as you are mindful about how & when you push to the central repo, it usually just works.
Using git checkout filename instead of git reset HEAD lets you pick your reverts more selective.
1

Because not always you want to commit all the changed files, you're able (and you SHOULD) to select which ones to commit. Depending on the project arch you are working with, sometimes you perform aditional changes for testing or something and not neccesarily for production.

Improve this answer

3 Comments

The OP is specifically asking about changed files.
True, although I'm more likely to create separate branches to handle those cases where I don't want to put a particular feature into the central repo yet. Just the way I work.
@Chris yes, but you could merge the 'feature' branch into the current one to build above and then only commit the 'non-feature' changes. You could rebase too but hey! There are thousands different workflows.
1

Another shortcut that should be mentioned here, that's not quite the heavy hammer of git add . is git add -u. The difference is that the former will stage any newly added files that aren't explicitly ignored (i.e. all 'untracked files' listed in the output of git status), while the latter will only stage modified files that were already tracked.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.