When using TFS, it is simple to exclude changes in Visual studio just by right clicking.
How can I do the same in VSTS which is now Azure devops? I have a repository with multiple solutions and i only want selected changes in a particular solution to be committed and pushed to the server. But how to perform this operation?
When using Git, you can stage changes you want to commit. If you have staged changes, all other unstaged changes will not be part of the commit. Staging a file is simply preparing it to be committed.
When you do not stage changes in Visual Studio, by default all changes are committed. See the left side of the image below: the button says 'Commit all'. The changes are all grouped together. If you commit like this, all changes would be committed.
In the right part of the image, you can see there are Changes, and Staged Changes. The commit button's text has changed to 'Commit Staged'. If you commit like this, the Notifications.cs file would be part of the commit, the News.cs would not be part of the commit.
You can (un)stage changes in Visual Studio by right clicking them and selecting (un)stage. You can also selecting the files to (un)stage and using the plus sign at the top right of the Changes to stage, and the minus sign at the top og the Staged Changes to unstage.
In short: by staging changes, you can determine which changes are included in the commit you're about to create. Here's some more information on Git Basics, the below information about staging can be found at the bottom of that article.
The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.
The basic Git workflow goes something like this:
You modify files in your working tree.
You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.
You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
Related
I made some changes to a few files within VS 2019.
I added a comment and clicked Commit All under Git Changes tab (didnt do a Push).
I realised i made a mistake by including some temp files so i clicked Revert under Git Repository Explorer against the comment i made.
All my changes have been lost in VS 2019..... Is there anyway to recover my changes?
Managed to resolve this after panicking a bit!! Just in case this helps anyone
Clicked Git in the VS 2019 menu.
View Branch History.
Under Local History, i right clicked the row where i made the changes and added my comment.
Selected Revert > accepted the warning
All my work was restored. I then continued to do the usual Commit and Push which then pushed my changes to the repo and i was able to verify that.
I Commited (call it Original). Then I made a bunch of changes.
Now I want to just roll them all back.
So I'm doing a Switch/Checkout. But I'm wondering if (and why) I need to Create New Branch (the default option).
First: Dropping commits means that you want to change the history. This might be problematic if you work with other people on a common repository and you already pushed your changes. - Either you do this rollback as described in the following text and force push (then you collaborators need to adjust their local history manually after pulling) or you revert the commits (option revert change by this commit) and push these changes (the revert is a normal commit which reverts the changes and will be automatically applied to your collaborators on pull).
If you really want to roll back all changes, the fastest way to go is to perform a "hard reset" to the revision you want to go back to (then the history and all files in the working tree are rolled back to the state of that revision, the other commits will be discarded as if those never happened).
If you want to keep one or more commits in the history, you should go for a rebase operation. Select the commit in the log dialog which should be the base for the "new" history and select "rebase onto this revision". Then flag all commits you want to drop as skip and perform the rebase.
cf. https://tortoisegit.org/docs/tortoisegit/tgit-dug-showlog.html#tgit-dug-showlog-actions and https://tortoisegit.org/docs/tortoisegit/tgit-dug-rebase.html
(Your itend to performa a "Switch" sounds like you have a SVN background; switch/checkout in Git means in generall that you want to switch to an existing branch or create a new branch).
see the documentation ...in that GUI it's called revert change by this commit:
Revert changes from which were made in the selected revision. All changes are integrated into your working tree. You may choose to commit immediately or edit and commit later. To abandon the reverted changes, perform a hard reset.
I'm using the standard xcode source control (version 9.3)
I just reopened my project and when I go to the Source Control Navigator:
It shows a long hex string at the top instead of the current branch name
None of the branches have '(current)' next to them
I have tried cleaning the project and also closing and re-opening.
Source Control->Commit brings up the standard commit interface with the option to leave a comment.
When I click on the very top row (with blue icon) I can see the new commits but they don't show in any of the branches.
What am I doing wrong?
This worked for me:
I clicked on the row with the long hex name. This brought up the version history for the current version.
I right-clicked the most recent change in the change history.
I clicked 'Branch from...' and created a new branch from that point.
For those wondering how something like this could have happened, it is caused when you checkout a commit rather than checkout a branch. Even if you checkout a commit inside the branch that is "current" (even the most recent commit), this will cause the branch to no longer have the "current" written next to it. So when you are sure that this previous commit that you have now checked out is the commit you want to work with, then you must do what Derek posted to do which is to "Branch from..." to make a temporary branch and then merge this temporary branch into the branch that this previous commit originally came from. And then you can delete the temporary branch. It is somewhat of a pain, but a good reason why Xcode does this is so that you are well aware that you are on a previous commit and that you should really make sure this previous commit is what you want your current branch to be at.
We use TFS for our source control system, but need to work with a contractor. We've set up a GitHub repo and I've been using git-tfs to move changes between the two. I'm not very familiar with git, and have managed to get myself into some trouble.
The git repo was in sync with the TFS repo. The contractor pushed a few commits to GitHub. After that, I checked in a few changes to TFS, then performed a git-tfs pull followed by syncing with GitHub (through the GitHub for Window application).
The changes I recently checked into TFS are in the GitHub repo. The changes from the contractor are in the GitHub repo and in my local repo, and I'm trying to get them into TFS. When I run git-tfs checkintool, I get:
Working with tfs remote: default
Basing from parent 'default:11102', use -i to override
Nothing to checkin!
If I run git-tfs rcheckin, I get the following. This shows the changes I'm trying to get into TFS, but notice the message at the bottom The item $/RDi/Software/System/SZ-Working3/EmbeddedGui is not a branch of $/RDi/Software/System/SZ-Working3/EmbeddedGui.. I think this is the problem, but I'm not sure how to rectify it.
Working with tfs remote: default
Basing from parent 'default:11102', use -i to override
Fetching changes from TFS to minimize possibility of late conflict...
Working on the merge commit: d2a85cd7b88715cabc6ed6cf5b9b7b5fc60359e0
Starting checkin of d2a85cd7 'Merge commit 'd36d26a6c6af5c1e89cf4dc7b2634964827b3ded'
Updated port screen PSD files. Should have what contractor needs regarding the animated arrows.
Replace language PSD files with new ones - the new ones contain the button pressed state for the OK/Cancel buttons.
Remove test file.
swiping removed from language page
Worked on issue 25: RemoteLib locks up when network settings update.
yes/no button added on language page'
edit .git\~w\QtJson/JObject.h
edit .git\~w\qml.qrc
add rsrc/images/480x272/common/no-small.png
add rsrc/images/480x272/common/yes-small.png
add rsrc/images/800x480/common/no-small.png
add rsrc/images/800x480/common/yes-small.png
edit .git\~w\rsrc/qml/pages/MetricsPage.qml
edit .git\~w\rsrc/qml/pages/RegionalSettingsEditorPage.qml
The item $/RDi/Software/System/SZ-Working3/EmbeddedGui is not a branch of $/RDi/Software/System/SZ-Working3/EmbeddedGui.
The item $/RDi/Software/System/SZ-Working3/EmbeddedGui is not a branch of $/RDi/Software/System/SZ-Working3/EmbeddedGui.
Native git allows partial commits: You can commit only some of the lines of your file and leave the rest for a later commit.
Is this possible in TortoiseGit?
Yes, there are official instructions in the docs.
In practice, I find this workflow useful:
Right click a file you want to partially commit
Click Restore after commit - This immediately creates an internal copy of the file.
Double click the file to edit in TortoiseGitMerge
Right click -> Mark this block for each change you want to commit now
Right click -> Leave only marked blocks to revert the other changes.
As an alternative to these two steps, you can edit the file the way you want.
Save and Close TortoiseGitMerge
Commit - this restores the internal copy of the file afterwards.
The changes you just reverted in TortoiseGitMerge are now restored in your working tree.
Update:
Starting with TortoiseGit 2.13 TortoiseGit comes with a partial staging feature in the commit dialog.
You need to enable the partial staging feature on the commit dialog, then the can open the patch view on the right side and select lines/hunks to stage/unstage.
The answer https://stackoverflow.com/a/32527098/3906760 is basically correct, however there are fewer steps required.
Choose Restore after commit in the context menu of the file you want to partially commit - This immediately creates an internal copy of the current state of the file.
Now adjust the file to only contain the changes you want to commit
This can be done using any editor you want to use, but also using TortoiseGitMerge:
Double click the file to edit in TortoiseGitMerge (or your configured diff tool)
Adjust the file to only contain the changes you want to commit.
Save and Close
Commit - this commits the selected files and restores the internal copy of the file - the original state of the file is now in your working tree again.
These steps are required as TortoiseGit does not yet support the full staging process and hunk/block selection, cf. https://tortoisegit.org/issue/2299.