GIT VS2017 plugin - who changed what and when?
In our company, it is my responsibility to measure output of coworkers.
In this context, it is our company's policy to push a git commit for each issue, with a commit message referencing an issue in Jira.
Now there are some coworkers whose output are horrible and don't obey this rule. When asked about their horrible performance, they end up giving lame excuses. I know for sure they're trying to fool me, but I can't prove it using GitLab's default commit history, since they only commit once every 2 weeks and thus all files changed on this specific date of commit.
Are there any tools so I can see what file changed when in Visual Studio, or other plugins or tools to measure/monitor output and changes in git, GitLab or Visual Studio 2017?
Edit:
We sure have a very open and free culture in our company. It's ok to look private things up, and we discuss and address a lot of non workrelated topics. But with freedom comes responsibility. For some its hard to handle this responsibility.
git visual-studio-2017 gitlab
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
add a comment |
In our company, it is my responsibility to measure output of coworkers.
In this context, it is our company's policy to push a git commit for each issue, with a commit message referencing an issue in Jira.
Now there are some coworkers whose output are horrible and don't obey this rule. When asked about their horrible performance, they end up giving lame excuses. I know for sure they're trying to fool me, but I can't prove it using GitLab's default commit history, since they only commit once every 2 weeks and thus all files changed on this specific date of commit.
Are there any tools so I can see what file changed when in Visual Studio, or other plugins or tools to measure/monitor output and changes in git, GitLab or Visual Studio 2017?
Edit:
We sure have a very open and free culture in our company. It's ok to look private things up, and we discuss and address a lot of non workrelated topics. But with freedom comes responsibility. For some its hard to handle this responsibility.
git visual-studio-2017 gitlab
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
5
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
2
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago
add a comment |
In our company, it is my responsibility to measure output of coworkers.
In this context, it is our company's policy to push a git commit for each issue, with a commit message referencing an issue in Jira.
Now there are some coworkers whose output are horrible and don't obey this rule. When asked about their horrible performance, they end up giving lame excuses. I know for sure they're trying to fool me, but I can't prove it using GitLab's default commit history, since they only commit once every 2 weeks and thus all files changed on this specific date of commit.
Are there any tools so I can see what file changed when in Visual Studio, or other plugins or tools to measure/monitor output and changes in git, GitLab or Visual Studio 2017?
Edit:
We sure have a very open and free culture in our company. It's ok to look private things up, and we discuss and address a lot of non workrelated topics. But with freedom comes responsibility. For some its hard to handle this responsibility.
git visual-studio-2017 gitlab
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
In our company, it is my responsibility to measure output of coworkers.
In this context, it is our company's policy to push a git commit for each issue, with a commit message referencing an issue in Jira.
Now there are some coworkers whose output are horrible and don't obey this rule. When asked about their horrible performance, they end up giving lame excuses. I know for sure they're trying to fool me, but I can't prove it using GitLab's default commit history, since they only commit once every 2 weeks and thus all files changed on this specific date of commit.
Are there any tools so I can see what file changed when in Visual Studio, or other plugins or tools to measure/monitor output and changes in git, GitLab or Visual Studio 2017?
Edit:
We sure have a very open and free culture in our company. It's ok to look private things up, and we discuss and address a lot of non workrelated topics. But with freedom comes responsibility. For some its hard to handle this responsibility.
git visual-studio-2017 gitlab
git visual-studio-2017 gitlab
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
edited 3 hours ago
Mark Rijsmus
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
asked 5 hours ago
Mark RijsmusMark Rijsmus
487315
487315
5
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
2
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago
add a comment |
5
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
2
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago
5
5
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
2
2
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago
add a comment |
2 Answers
2
active
oldest
votes
There may be a few issues here:
- The items those coworkers get are 'large' and define more than one issue.
- The coworkers don't make atomic commits
- The one managing them can't trace their work time back to a specific timestamps.
The first issue is a hard one. Try to make the issues as small as possible and only define one item to do in it. If a task/userstory is too big, define either new userstories or smaller tasks. Refine these items with the developer itself and let them guess their time on it.
The second issue is more an issue developing. Why would you want atomic commits?
- Code reviews are easier
- Easier to rollback changes
- Easier to make changes
- Better history
This should be in your company's / team standard on how to commit things. They either do this or they don't. If they don't try to get them to change.
The third issue is a result of slacking on the atomic commits, however can be avoided if time is registered at the issue itself. However this again needs to be done by the worker itself. A good thing may be to pair him up with someone who does it right and show him how to do it correctly. As for a tool, i don't know any timetracking plugin so a manager can check their times. You shouldn't look for this in git.
answered 4 hours ago
Baklap4Baklap4
1,56011236
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
add a comment |
Try using Gitlense. It is a VSCode plugin. Works for me when working with a team.
answered 4 hours ago
Amit KAmit K
193
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54249680%2fgit-vs2017-plugin-who-changed-what-and-when%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There may be a few issues here:
- The items those coworkers get are 'large' and define more than one issue.
- The coworkers don't make atomic commits
- The one managing them can't trace their work time back to a specific timestamps.
The first issue is a hard one. Try to make the issues as small as possible and only define one item to do in it. If a task/userstory is too big, define either new userstories or smaller tasks. Refine these items with the developer itself and let them guess their time on it.
The second issue is more an issue developing. Why would you want atomic commits?
- Code reviews are easier
- Easier to rollback changes
- Easier to make changes
- Better history
This should be in your company's / team standard on how to commit things. They either do this or they don't. If they don't try to get them to change.
The third issue is a result of slacking on the atomic commits, however can be avoided if time is registered at the issue itself. However this again needs to be done by the worker itself. A good thing may be to pair him up with someone who does it right and show him how to do it correctly. As for a tool, i don't know any timetracking plugin so a manager can check their times. You shouldn't look for this in git.
answered 4 hours ago
Baklap4Baklap4
1,56011236
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
add a comment |
There may be a few issues here:
- The items those coworkers get are 'large' and define more than one issue.
- The coworkers don't make atomic commits
- The one managing them can't trace their work time back to a specific timestamps.
The first issue is a hard one. Try to make the issues as small as possible and only define one item to do in it. If a task/userstory is too big, define either new userstories or smaller tasks. Refine these items with the developer itself and let them guess their time on it.
The second issue is more an issue developing. Why would you want atomic commits?
- Code reviews are easier
- Easier to rollback changes
- Easier to make changes
- Better history
This should be in your company's / team standard on how to commit things. They either do this or they don't. If they don't try to get them to change.
The third issue is a result of slacking on the atomic commits, however can be avoided if time is registered at the issue itself. However this again needs to be done by the worker itself. A good thing may be to pair him up with someone who does it right and show him how to do it correctly. As for a tool, i don't know any timetracking plugin so a manager can check their times. You shouldn't look for this in git.
answered 4 hours ago
Baklap4Baklap4
1,56011236
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
add a comment |
There may be a few issues here:
- The items those coworkers get are 'large' and define more than one issue.
- The coworkers don't make atomic commits
- The one managing them can't trace their work time back to a specific timestamps.
The first issue is a hard one. Try to make the issues as small as possible and only define one item to do in it. If a task/userstory is too big, define either new userstories or smaller tasks. Refine these items with the developer itself and let them guess their time on it.
The second issue is more an issue developing. Why would you want atomic commits?
- Code reviews are easier
- Easier to rollback changes
- Easier to make changes
- Better history
This should be in your company's / team standard on how to commit things. They either do this or they don't. If they don't try to get them to change.
The third issue is a result of slacking on the atomic commits, however can be avoided if time is registered at the issue itself. However this again needs to be done by the worker itself. A good thing may be to pair him up with someone who does it right and show him how to do it correctly. As for a tool, i don't know any timetracking plugin so a manager can check their times. You shouldn't look for this in git.
answered 4 hours ago
Baklap4Baklap4
1,56011236
There may be a few issues here:
- The items those coworkers get are 'large' and define more than one issue.
- The coworkers don't make atomic commits
- The one managing them can't trace their work time back to a specific timestamps.
The first issue is a hard one. Try to make the issues as small as possible and only define one item to do in it. If a task/userstory is too big, define either new userstories or smaller tasks. Refine these items with the developer itself and let them guess their time on it.
The second issue is more an issue developing. Why would you want atomic commits?
- Code reviews are easier
- Easier to rollback changes
- Easier to make changes
- Better history
This should be in your company's / team standard on how to commit things. They either do this or they don't. If they don't try to get them to change.
The third issue is a result of slacking on the atomic commits, however can be avoided if time is registered at the issue itself. However this again needs to be done by the worker itself. A good thing may be to pair him up with someone who does it right and show him how to do it correctly. As for a tool, i don't know any timetracking plugin so a manager can check their times. You shouldn't look for this in git.
answered 4 hours ago
Baklap4Baklap4
1,56011236
answered 4 hours ago
Baklap4Baklap4
1,56011236
answered 4 hours ago
Baklap4Baklap4
1,56011236
answered 4 hours ago
Baklap4Baklap4
1,56011236
1,56011236
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
add a comment |
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
Thnx. I think we'll go for the atomic commits solution. Its the most positive solution and best suits our company's free culture.
– Mark Rijsmus
3 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
I consider a combination of 1 and 2 to be a golden combi. If the issues are as small as possible you may even 'fit' for just one commit. Besides it'll make items get to be done earlier and be tested aswell. Also i'd introduce code reviews to make sure the commits are as atomic as can be.
– Baklap4
2 hours ago
add a comment |
Try using Gitlense. It is a VSCode plugin. Works for me when working with a team.
answered 4 hours ago
Amit KAmit K
193
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
add a comment |
Try using Gitlense. It is a VSCode plugin. Works for me when working with a team.
answered 4 hours ago
Amit KAmit K
193
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
add a comment |
Try using Gitlense. It is a VSCode plugin. Works for me when working with a team.
answered 4 hours ago
Amit KAmit K
193
Try using Gitlense. It is a VSCode plugin. Works for me when working with a team.
answered 4 hours ago
Amit KAmit K
193
answered 4 hours ago
Amit KAmit K
193
answered 4 hours ago
Amit KAmit K
193
answered 4 hours ago
Amit KAmit K
193
193
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
add a comment |
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
3
3
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
The sad thing is, if you commit you'll make your history. If that happens just once every 2 weeks.. there's still no use in making that visual with gitlense
– Baklap4
4 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
Gitlense gives you an option of going back and forth in commits. Also, it gives you commit message and author based on the line you are at.
– Amit K
3 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
It does, however you do have to commit that's the problem OP is facing. The workers don't commit that often...
– Baklap4
2 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54249680%2fgit-vs2017-plugin-who-changed-what-and-when%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
What a healthy-sounding culture.
– jonrsharpe
4 hours ago
Moreover we have a great working atmosphere, but some people just push to far and cant handle this responsibility.
– Mark Rijsmus
4 hours ago
2
Instead, introduce code review and reject pull-requests that consist of such non-atomic commits?
– alfunx
3 hours ago