Disable automatic commit of changed files in Visua

Question

Problem:

When I add a new file into a web project in VS 2013, it is immediately "checked in" to git; the file is immediately saved and then the "check in" icon appears to the left of the file. If I make a change to an existing file, the moment I save the file it "checks in". Please note that the source git repository is not modified, but I think my local repository is being checked into.

Expected behavior:

Add a new file or change an existing one, save, file stays "checked out" and must be manually checked in when ready. This is the desired behavior and was how this project behaved until it started behaving as described on a coworker's system and subsequently appeared on two of my systems.

Background:

My coworker managed to return the source control process back to what it was originally by trying a couple dozen different techniques - deletes, resets, etc., but doesn't know what she did to specifically fix it. I did the same on one computer and haven't been able to resolve it, but on my other system I also swung wildly in my approaches and managed to get it working.

If I go to the git command line from VS 2013 and enter "git status", I see a list of changed files, but no files that were added. Just above this list of files is the text:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

I am very familiar with TFS and SourceSafe, but this is the first time I've worked with git. I know that they are very different beasts in their approach to source control and also realize that my terminology (i.e. check in, check out) is more TFS/SS-oriented, so please forgive the error in wording.

Project Info:

This is a VS web project using Angular and Breeze as well as Bower to manage packages. The projects that are working "correctly" do not use Angular, Breeze, or Bower.

Conclusion:

Can anyone either tell me what is going on here or if there is some way to get my project back to the initial behavior it exhibited? Thank you in advance.

Answer 1

The problem I was having with my project was that my .gitignore file was empty. Upon copying in the contents of a .gitignore file from a project that was working properly, Visual Studio returned back to showing me my changed items, icons beside the files in the Solution Explorer represented the proper state of a file (i.e. changed, added, etc.). I don't understand git enough to know why this fixes the problem, but I wanted to post this out here in case anyone else ran across this.

Answer 2

Git does not behave the way other version control systems behave. The terms "check-in" and "checkout" don't mean the same thing in Git as they do in TFVC or SourceSafe, which could be where your confusion lies.

With SourceSafe, when you "checkout" a file, you're telling the version control system that you intend to edit a file, and this blocks other users from editing it in the meantime. This stems from the fact that tools like SourceSafe and TFVC are centralized, as opposed to Git, which is decentralized. With centralized version control systems, everyone is editing the same copy of a file, which is why it becomes necessary to lock and unlock specific files for editing.

With Git, you can edit any file at any time, because you're making those edits against your own local copy of the repository. Once you're satisfied with the changes, you push them up to a remote repository, which in your case is probably the repository hosted on your TFS server and associated with your Team Project. There's no gatekeeping behavior to prevent you from making edits, because it isn't necessary. So with Git, a "checkout" is simply a fetch - you tell Git what branch and/or commit you want to load up.

With SourceSafe, you perform a "check-in" to finalize your changes and push them to the central repository. This frees up the file for editing by other users.

With Git, things are a bit different. You "commit" changes to your local repository, and then periodically "push" those changes to the remote (shared) repository that your team uses to synchronize changes. Since other users are making edits against their own clones of the repository, there's no need for unlocking files by checking them in.

Another thing that's different about Git is that you can stage or un-stage pending changes. Only changes that have been staged by an "add" will be pulled into a commit. Visual Studio basically takes care of this for you with "Included Changes" vs "Excluded Changes". Essentially, if VS shows a given change as included, then it has been (or will be) staged in Git and will eventually be committed when you hit "Commit".

Regarding the visual cues you're seeing: I believe what you're seeing is Visual Studio telling you that a file has been modified, not that it has been checked-in. When you make edits in a solution associated with a Git repository, VS will show a red check mark to the left of each modified file in the Solution Explorer window to indicate that it has been edited and has changes pending. (New files that have been added will show a green plus-sign next to them.) All this means is that the file has been changed - it is still up to you, the user, to commit or abandon the changes. Once you've committed your changes, you can Sync with the remote repository to publish your changes to the rest of the team. At this point, if there are any conflicts between other team members' changes and yours, and they're not easily merged, Git/VS will stop and ask you to manually reconcile the conflicts.

In your case, Git/VS isn't doing any automatic check-in. It's simply indicating that certain files have pending changes.

A full Git tutorial would be beyond the scope of this answer, so I would recommend doing some reading on your own to get a better understanding of how Git works under the hood and how Visual Studio is interacting with it.