I did some version changes in my project and commit those. But I cannot Sync those and push to the server. SO that I cannot make a pull request in bitbucket?
I am using Visual studio 2017
It Shows the error message"Failed to push to the remote repository. See the Output window for more details."
In the out window, it display "One of your commit messages is missing a valid issue key:"
Can any one please help me? I am new to this.
The actual error message is:
One of your commit messages is missing a valid issue key:
Most likely, this is being caused by either a client or server side Git hook. The fix here is probably to check the commits you have made since last pulling the branch, and verify that each one has an issue key/number.
As to why the Git hook is ensuring that each commit has an issue key, it is to ensure that your commit history can easily be correlated with your team's issue tracker tool (such as Jira or Trello).
I found a solution for my above problem.
In there it displayed a Error message called "One of your commit messages is missing a valid issue key".
For solve this I click on my current working branch and go to "View History". Then you can see all the commit messages and your branch history in Visual Studio.
Then you should identify which commit have the issue. Some times it may be a space in your gira task id.
Then double click on the comment that have the issue.If it is your lastly updated commit then you can directly edit that commit message and click on "ammend message".Then your commit is again in the changes tab in your Visual studio.
If it is not your lastly update commit then you have to click on the "Reset" "Reset and keep changes" and refresh your history tab in your visual studio until the issue comment become the first. Then you can edit the commit message and "ammend" it.
Related
I was trying to migrate/upgrade a solution(Database project) from VSS to Git.
After a few operations(like disconnect the source control, upgrade project file, etc), I found out the most of the options in team explorer are gone.
Now there is only Settings left but there suppose to have Changes, Braches, Sync. Like
And the worst is, I thought it's because I messed up something in the solution(local repository) but I found out that all repositories now behave the same when I open them by Visual studio.
What should I do to fix this situation?
It seems perhaps one of my operations disconnect me from Git instead of VSS cause those options resume after I reconnect to TFS Git proactively.
I ran into the same problem again. It seems VSS2Git somehow dis-attached the repo from Team Explorer so you can see it shows Offline caption right after Home.
Solution
1. In Team Explorer, switch to connect tab.
2. Under local git repositories clicks Add and select the repo you want.
3. Double click the repo you picked in the previous step to attach it.
4. Now you should be able to have correct home page with repo you are targeting.
After steps above, if you lost entries in Solution Explorer, means the VSS didn't unbind fully by VSS. Try the following
File > Source Control > Change Source Control
Unbind project which still sticks with VSS
We are just starting to really use VSTS and VS2017 together.
When I add a related work item to a commit from within VS-2017 can the state of that work item be changed?
If the item is new, it shows the commit on VSTS but does not change the state to done or any thing else, it just leaves it as new.
Am I not following the expected work flow correctly?
No, work item state can not be changed through commit message now.
For now, VSTS only support to link work items through commit message (#workitemID). The feature for changing work item state through commit message is not available.
But there has an user voice Update work items on commit for git which suggests this feature, you can vote and follow up.
For TFVC, yes, that can be done.
Since you're using Git, no, it can't. When you commit with Git, it's a local operation. It wouldn't make sense to complete a work item when you make a local commit.
With Git, the normal method of working is to create a local branch to work, commit locally against that branch, then push the branch.
After you've pushed the branch, you can submit your changes to a stable, long-lived branch via a pull request. As part of completing a pull request, you can choose to have it complete all of the associated work items.
I've been happily developing away on a Sitecore project for the last couple of months. This evening I did what I have done 100 times, smart published the entire site so that I could view it from the web DB as an end user.
When I navigated to the site I discovered that all of my content is gone. All rendering elements are there, but anything in the /sitecore/content tree is missing on the page. Gone. Empty. Nada.
Everything looks fine when I'm logged in and viewing in Page Editor.
I've done several smart publishes and still the same. I was going to try a republish of everything, but after reading the warning dialog I thought I'd wait until I understand what happened.
This is a pretty disconcerting thing. Any one have any ideas?
Check your root or home item , make sure it is in publishable state and check if it published. If the root item is gone your will not see anything on the site.
There are multiple things you will want to check on your root node where content is missing:
Workflow state: If there is only one version, but the workflow state was changed to a non-final version manually, it will not be published.
Publishing Restrictions Publishable state: If the 'Publishable' checkbox has been disabled for any item or version, that item/version will not publish.
Publishing Restrictions by Date: If a date-based publishing restriction has been applied to the item or versions, the item may have been removed because it is no longer in a publishable date range.
If this is on Sitecore 7.2, i think there is a bug where content items just disappear:
http://maxslabyak.com/sitecore/3-new-sitecore-v7-2-bugs-need-know-go-live/
To Fix it, set this setting Publishing.PublishEmptyItems to true
Hope this helps
I have done a number of changes to a build configuration in TeamCity 8. I know I can see an audit trail of the changes that I have done to the build configuration and I can check the details of each individual change, but I wonder if I can select one of those previous versions of the build configuration and restore it; there doesn't seem to be any obvious option in TeamCity for this.
For the avoidance of doubt, I'm not after reverting changes in the source code, but in the build configuration of TeamCity. I changed a few parameters, build steps, triggers, etc., and I want to revert those changes.
You are right ,there is no obvious option in Teamcity to rollback to a previous version.
However, all teamcity build configurations are maintained in a xml file on the local disk drive in the Local Build Server. The files are created in a rolling format (the latest config is called config.xml, the one previous to it is config-1..xml). If you can figure out from the audit page on which exact xml you want to rollback to, you can copy the backed up config.xml to the recent one, or you can make the changes manually.
I would recommend playing with this on a test target first and then doing it on the original target.
As of TeamCity 2017, there is a link to a page with recent changes to a configuration:
Press 'view history' and you will end up on a page where there's a list of changes.
Press 'view change':
There you will see a "diff" comparison, identical to the one you have in git:
Sometimes it's hard to navigate, but you can surely see what was changed. This is especially useful for accidents when you deleted a piece of script, and saved the configuration. This can get your script back.
Hope it helps you after you after 8 years and 4 months!
What is the great motivation behind integrating Redmine with a source control repository ? If it is only for monitoring reason, developers already have access to repository and they can do whatever they want diff, history with their IDE. For other people do they really need? I'm afraid, I can't see the real reason. Can you please help me to see ?
When you fix a bug that exists in Redmine's issue tracker, you can refer to the issue id in the commit message and Redmine will automatically associate the commit with the issue (or even close the issue).
This saves you the double work of referring the issue in the commit message and closing the issue in Redmine.
By the way, this is not Redmine-specific - you can do it with most bug trackers that offer source control integration.
I don't remember the exact syntax in Redmine right now, but most of the time, the syntax is something like:
fixes #123
...which would cause Redmine to automatically close issue #123, and create a link from the issue to the commit (and vice-versa).