Any way to see another developer's uncommitted changes?

Question

Back in the days of TFVC (in TFS), you could see who checked out code and then never checked it back in.

Developers often forget to commit their changes before taking off for the day (or at all), so as a lead I would use that feature to go squawk at someone to check in their work.

Is there any way to do this with git? I find myself missing this feature more and more every day

Answer 1

The title question is misleading, because you can't do this in TFS (VSTS) either:

Any way to see another developer's uncommitted changes?

In Git you can't necessarily see even committed changes, let alone uncommitted. In both Git and VSTS, unless you have access to the developer's machine, you can't see what the developer is doing until they send some changes to the server. In Git, this would be a developer committing locally, and then also pushing those commits to the server, perhaps on a personal branch. In VSTS, the closest equivalent of this would be creating a shelveset which is stored on the server for others to see.

I realize you then clarified what you're actually asking about:

Back in the days of TFS [VSTS], you could see who checked out code and then never checked it back in.

Note that's something different than even seeing what someone is working on. Case in point: sometimes in VSTS, when I was working in a project where checking out a file was configured as an exclusive lock, I would attempt to checkout a file only to discover it was already checked out by another developer, months ago. Of course they weren't working on it, I'd contact them, ask them to unlock it, and they'd apologize and do so. My point is, looking at what files someone has checked out doesn't necessarily translate to what someone is actually working on, but instead merely represents intent to edit, at some point in the past. That being said, I suppose if someone looked at all checked out files daily as you mentioned you had done, or even weekly, perhaps those devs could have been nudged to either check-in the files, or undo the checkout. In our case, after a while the locking issue became annoying enough that we eventually removed the exclusivity. If we later had conflicts we simply resolved them. (BTW, an interesting side effect of this was that people that were uncomfortable merging, were more likely to try to get their code checked-in faster when they knew someone else was also working on the same file, just so they didn't have to be the one to resolve merge conflicts.)

In Git, it's not necessary to have exclusive locks on files, and therefore the concept doesn't exist. So, given that, and what you actually gained from exclusive locks in VSTS, perhaps a more correct title sounds much less interesting:

Any way to see what other developer's might be working on?

The answer in Git is mostly No. But you would/should know what they're working on based on your issue tracker, and team standups if you're in an agile environment. At my company we have a branch naming convention that may help with this as well. Developers name their branches like user/first.last/123456-add-new-thing where 123456 is the issue number. We encourage devs to commit early and often, and push at least at the end of the day to serve as a backup of their work. In theory you could go look at any devs' branches to see what they're working on. I tend to prefix my commits with "wip:" at the end of the day when I push to signify to myself to rebase or amend in the morning.

Summary: the confusion here is cleared up by the fact that exclusive locks aren't needed in Git due to the superior merging capabilities, and in VSTS, checking out a file doesn't actually let you see the changes a developer is making anyway, until they create a shelveset containing those files.

Answer 2

The answer to your question as posed is no. The answer to the question I think you were trying to ask is yes. I think you are asking how to improve visibility of developer activity. You can achieve this by setting up your dev process appropriately.

Git doesn't work like TFS or other server based version control systems. With git everyone has their own private repo and there's strong support for merging. The people in your team are committing to their local repo and occasionally pushing changes to whatever repo they designate as "upstream" in the .git/config file of that repo.

There are lots of git workflows. This one will address your particular need but you should get a git book and think about all of them.

To get the behaviour you seem to want you can set up a repo designated as "the" repo (often hosted by GitHub or Azure Devops) and require everyone to designate this as their upstream. Things are automatically set up like this if they create their repo by cloning from a GitHub repo.

Now, you don't want them merging every little scrap change and experiment into upstream/main, apart from making the history a real mess their half finished work would interfere with others. So what you want them to do when they start a sprint is pull latest from upstream/main and then on their workstation create a branch named for the work item feature/add-pink-widget-support.

Doing it this way has the following desirable outcomes.

• They can push half finished changes in that branch to the upstream repo as often as they like without causing trouble for others.
• Their work is implicitly backed up off site every time they do this.
• You can see all their changes.
• You can test on that branch.
• When everything is done for that work item and it all tests ok you can merge to main in one go.

You said "uncommitted" changes. This won't show those to you, but doing things this way removes the reasons for not wanting to commit changes. Nobody wants to be the guy who broke the build in CICD, so a distinct branch is a way for you and your dev to partition his changes off from main branch until they are ready.

Actually uncommitted changes exist only in the file system of the dev's workstation. They are a risk and with private branches they should really only exist for things like local config.

Why is git so totally different in approach? Everyone has their own repo. Once you have that, you can unplug from the network and keep coding and still have source control. Then later you get back on the net and you can push your changes to other repositories.

Merging is something you have to do eventually with more than one developer in play. The philosophy behind Git says that if we make this the central capability and support it well, not only is it less grief to merge, this buys us decentralisation, redundancy and other benefits.

Git can be difficult to come to terms with. I hope I have correctly divined your need and assisted with it.

Answer 3

Is there any way to do this with git?

No. Git provides no functionality for "checking out" files to indicate you're working on them, and "Checkout" in Git means something entirely different.

Git was designed to support many thousands of concurrent developers on a single project with no strong management hierarchy, where contention over locked files would effectively stall development.

Each developer has a complete local clone of the repository and its entire history. There is no way to tell who may be working on some specific files, or which files a specific developer may be working on, because they are working against this completely decoupled local clone.

Instead of exclusively locking files, Git emphasis good tools for detecting and fixing merge conflicts when they occur. Asking developers to make small atomic commits helps.

Because a developer doesn't need to lock files prior to working on them, there is no need to remind developers to unlock files at the end of the day.

If you want to know who has work-in-progress, you would typically track that in a ticketing system instead of your VCS, and watch for tickets that stall on their way across some form of agile board.