Back in the days of 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

CodePudding user response：

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.

CodePudding user response：

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.