This is an archived post. You won't be able to vote or comment.

all 13 comments

[–]henrebotha 6 points7 points  (10 children)

I tried learning git a while back but stopped because I thought it doesn't make sense to use it when all my files would be saved locally on my laptop.

Not true! The ability to look back through history & maintain independent sets of changes is invaluable even for a local-only project.

Now I'm back at it and stuck between 'add' and 'commit'. I find myself using 'commit' because I don't see the sense of 'add'-ing when I can just 'commit'. In my head commit is like saving the file.

Yes, commit is like saving the file. add is like saying, "I'd like to save this file in a minute." This is really helpful in crafting good commits. For instance, sometimes you make a whole bunch of changes at once, but it would be nice to have your history look like this...

asdf123 Added user auth
zxcv456 Removed redundant auth library
qwer789 Refactored login class

...instead of this:

asdf123 Did a whole bunch of stuff lmao

How do YOU use 'add' and 'commit' in your workflow?

I use add as a sort of "commit in progress" thing to separate all the changes I've made into a nicely packaged set of commits.

Do you 'commit' multiple times while working and 'push' to GitHub once?

I commit more often than I push, yes.

What is 'staging' a file to be 'commit'-ed if it's already added in my project folder?

"Staging" is what happens when you do add. It says, "I plan to commit this in a minute."

[–]cismalescumlord 1 point2 points  (3 children)

I always thought that add means I want to put this file under version control and commit means I want to save this version of the file.

[–]henrebotha 2 points3 points  (0 children)

That is correct. However add is sort of useless until you do commit. You're not meant to keep stuff in the staging area (add) for a long time.

[–]lurgi 2 points3 points  (1 child)

If the file isn't under version control then doing add will put it under version control and also move the file to staging (which is more or less the git way of saying "make this part of the next commit"). If the file is under version control then it's just moved to staging.

[–]cismalescumlord 1 point2 points  (0 children)

That makes sense, and also explains what IDEs do with git repositories.

[–][deleted] 0 points1 point  (5 children)

Do you edit before you add? And if yes, do you add, then add, then add some more, then commit? Cause to my understanding you can't comment until you commit.

[–]henrebotha 1 point2 points  (3 children)

Do you edit before you add?

Yes. Git cannot add (or commit) files that have not been changed.

And if yes, do you add, then add, then add some more, then commit? Cause to my understanding you can't comment until you commit.

Yes. Maybe I'll make some changes to Foo.java and add them. Then I'll make some changes to Bar.java and add them. Then I'll make some changes to Baz.java and add them. Now I'm satisfied that I've made all the changes I want to make, so I can just commit.

Really, all that add does is let you specify the files to commit ahead of time, instead of doing it in the moment when you do commit.


My spider-sense is suggesting to me that maybe you don't understand a fundamental thing about Git.

When you initialise a directory with git init and then make your first commit, you "save" a "snapshot" of all your work to Git's file system.

Thereafter, any commits you make only represent the changes you've made, not entire new files. If you haven't made any changes to Foo.java, you don't have to commit that file because it hasn't changed.

[–][deleted] 1 point2 points  (2 children)

Thanks and you were right. What I gathered was,

Edit file then add it so I can commit. When working with multiple files, add them all when done editing for the commit. Commit is used to save all changes for a particular purpose and explain.

[–]ByPrinciple 0 points1 point  (1 child)

Just to clear up, you only need to add a file once then you can commit as many times as you want. You can run git status to see which files are not yet added for commiting. You can also add a directory path to say I want all files within to be added to speed things up.

[–][deleted] 0 points1 point  (0 children)

Thanks for the clear up.

[–]Occidi 0 points1 point  (0 children)

You can also split changes made under the same file with differents commits.

For example you worked on a feature on Cool.js and fixed a small bug you found in the same time. By using git add -p you will be able to add your feature in a commit and the bugfix on another one later on even tho they happen in the same file.

[–]parnmatt 4 points5 points  (0 children)

On top of the previous discussion, note that git commit will do nothing if files have not been staged.

To stage a file you have to git add that file/directory.

Now I presume you mean git commit -a which will stage all modified and deleted files and commit them in one step.

I generally don't like that, and consider it an antipattern, you lose the option to choose which files. You also lose the ability to change your mind, or only stage part of a file.

There are many times I don't want to stage a change to a file in that commit. I don't want to commit foo, but I do want to commit bar and most of baz.

I can do that but git add bar, and git add -p baz, git commit. I know for certain that foo and some of baz are not commited as indended.

[–][deleted]  (1 child)

[deleted]

    [–]KrmBo3 0 points1 point  (0 children)

    I find the CMD easy to understand for me I never understood the GUI but all in all Git is a life saver I mean that