We have been using tortoise svn for quite a while and loved it.
When we did an update it would automatically merge and if there were conflicts
it would produce a conflict file and I could use the merge tool on it.
With tortoisegit, if someone has been in the file it does not even attempt to
merge just produces message similar to "Cant". Is this a problem with git or
tortoisegit. We used tortoisegit because of how easy tortoise svn was to use and did not get in the way. Whereas with tortoise git we get the "CANT" and many dialogs to
click on when we do anything.
How can I merge in tortoisegit if there is a conflict, and is there someway to tell
it to produce conflict files.
I will try to summarize how Git synchronization with remote repository works.
You Commit your changes into a local branch.
You want to Push your changes into remote repository. If Git finds out there are new changes in remote tracking branch, it will not allow the Push and will say "you have to do Pull first". (This is a restriction in the Git itself, not only in TortoiseGit.)
As per instructions you do Pull. New merge commit combining yours and others' changes has to be created. If there is no conflict, merge commit is created automatically. If there is a conflict, TortoiseGit force you to resolve it and Commit changes manually.
Finally, you do Push.
I think the main difference from SVN schema is the creation of merge commit, but I don't see this as a disadvantage at all.
A good way to avoid merge commits is to always do Pull before committing so you commit to the newest version of the branch. However if you have working tree changes in a file which needs to be updated during Pull, Git will say Your local changes to the following files would be overwritten by merge and Please commit your changes or stash them before you merge. In this case you should do Stash changes, repeat Pull and finally do Stash Pop.
You may call all these operations from TortoiseGit context menu or you may try to use Git Sync dialog.
Related
Hello so I've done this before I just completely forgot how.
What I am trying to do is I have a remote on my github repo and I have an old version that I would like to revert to meaning I can commit from it and it would now be at the top of the repo if that makes sense since my current repo is having some issues and I want to go back to a specific version.
I remeber slightly what I was able to find out last time which worked out beautfully and that was I checked out the version I want and then I created a new remote or split the remote or something, added the version on to the new one and then merged the branches or remotes. It was something along those lines, I just don't remember exaclty and I would appreciate someone guiding me through as I am unable to find the old posts I was previously looking at.
This is a Swift Xcode project
Thank you in advance for all of the help
Instead of rebasing/restting your branch, you could revert the past commits you don't want, in order to create a new commit which would restore the state of the branch to the content of an older commit.
See "Git reset --hard and a remote repository"
git revert HEAD~N
git push
Using terminal git, you can do git rebase -i HEAD~N where N is the number of commits you want to backtrack. Then you can choose to drop or edit commits. In your case, you only need to drop the most recent commits and then you will be effectively back to one of your previous commits. In other cases, this can be used to combine/split commits as well.
Hypothetical:
I'm working on a project and let's say I create a branch table-settings off of master. I commit changes to three files:
plate.swift
bowl.swift
fork.swift
Someone comments on my pull request and says, "We don't need those changes to plate.swift right now.
Either on github, the command line, or a source control desktop app, is there a way that I can revert all changes to a single file in a commit or pull request, back to the state it was in when I created the branch?
What makes this different from "How do I revert a file to the previous commit", is that I'm wondering if I can revert a file that's been edited and committed multiple times, to the state that it was at when I created the feature branch it's on.
If you want to make it to a state that's in master then do following from your branch
git checkout master -- /path/to/plate.swift
above command will make it to a state, that's in master. Then commit and push normally. e.g.
git commit -m 'reverting not-required changes'
git push;
Thanks!
The duplicate link in the comments basically has you covered, but in this situation I might be inclined to do the following:
git checkout HEAD~1 path/to/plate.swift
This will reset plate.swift to the version one revision prior, when you created the branch. Then you can amend the commit via
git commit --amend
Now your commit will contain all the previous changes minus the changes to plate.swift, which file will appear unchanged. You would then have to force push using this:
git push --force origin table-settings
The reason the force push is needed is because we have rewritten the last commit in the branch. But this approach is possibly nice for the reviewers, who will see a feature branch which looks very similar as when they commented.
If your feature branch has already been checked out by reviewers, then a safer option would be to just do a normal commit:
git commit -m 'reverted Plate.swift'
But I have found that amending can be useful when you end up having to make a number of tweaks to a pull request but you don't want to uglify your branch's history with many commits.
I am still learning the features of using TortoiseGit and the concept of version control.
I have read the this article and it is not clear to me if I need to follow that procedure. It describes patching.
So, I have this feature branch that has now been merged into the master as indicated. I want to have a go at making a revision to the application with respects to one of the commits (highlighted). So I would like to try out an idea to do things differently and implement it if I am happy.
What is the correct way to do this? I am a sole developer and am not in collaboration with others for my project.
Thank you for your advice.
There will always be times when you realize that a commit is not perfect or introduced an error.
You have several options:
1) Fix the issue and commit the fix on master (or in a bugfix/feature branch). You should do this, especially, if the "faulty" commit is some longer time ago.
2) Option 1 might have the disadvantage that you don't know that this fix belogs to a recent feature branch. Here, you could switch to the feature branch again (if you already deleted the branch, re-create it on the latest commit before the merge), commit the fix there and merge the feature branch again to master. This way you can see in the log that this fix also belongs to the feature branch.
3) The third option would be to rewrite your history - the is especially discouraged if you develop with other users and the "faulty" commit is already pushed or older. For rewriting history, go to the log dialog and open the context menu on the commit just before the faulty commit and select "Rebase ... onto this". Then the rebase dialog opens, check "Preserve merges" and "Force" there - then all commits starting with the "faulty" one should be displayed. Now, click on the "faulty" commit and mark it as "Edit" and then start the rebase. - Now your working tree is put back into that old state. Do your changes on the working tree, check "Edit/Split commit" and click on "Amend" on the rebase dialog. - After that all other remaining commits are re-applied and the fix is included in your history.
PS: The article about patches and pull requests is about sharing changes with other developers.
If you are sole developer and you are absolutely sure that no external party has checked out your master you can do the following:
Create backup of your master branch by branching off from the top of current master.
Looks like you also have changes committed to your master branch. Create a feature branch on from the master as well. At this point master-backup branch and your new-branch should be identical
Reset your master to the state before your merged in your feature branch. In this case this is 'Removed MWB files....'
Checkout your feature branch you want to change
Do git rebase -i master
Edit the line that has your commit that you want to change. Change 'pick' to 'e' and save the file to kick off interactive rebase
When rebase stops at the commit you want to change do git reset HEAD~ this will put your working directory into the state before you did your commit. With all changes being on the index.
Make necessary changes to your source and commit
Do git rebase continue
Once interactive rebase finishes. Checkout master and merge your new feature branch into int.
Checkout your next branch 'lingala' translation.
Rebase it on top of new master, and then merge
Checkout your feature/new-branch, and rebase on top of new master then merge
You done. Push everything to your remote. Note that you have to use 'git push --force'
If you have code checkout on other machines, make sure to do the following
git fetch ;
git checkout master ;
git reset --hard origin/master
Note the last step will destroy any local changes you have on your master branch and any uncommitted files. If you want to preserve them either stash them or create a temp local branch that you can later rebase on top of new master
If you don't want to preserve your history tree as is just do the following steps:
Start interactive rebase git rebase -i 'xxxxxxx' where xxxxxx is commit id of the commit with the comment 'Removed MWB files....'
In your rebase sheet edit the line of the commit that you want to change by replacing 'pick' with 'edit'
When rebase stops. Do 'git reset HEAD~' this will put your working directory into the state that was right before you committed these changes.
Make changes to your files, commit them.
Do git rebase --continue
Push your master branch with --force option
PROFIT
BEFORE YOU DO THIS. MAKE SURE TO CREATE A BACKUP COPY OF YOUR MASTER BRANCH
If something goes wrong you can restore master branch from the backup by doing
git checkout master
git reset --hard backup-master
git push --force
I'm trying to get a feel for how to do certain things in TortoiseGit that are pretty intuitive in TortoiseHG.
TortoiseHG has the Workbench which basically is my central tool to sync the local repository with remote ones: upstreams and origin.
It is easy to see what changes I'm missing locally (so I need to fetch them) or remotely (so I need to push them).
What is similar functionality in TortoiseGit?
How can I see a list of changes from a remote origin or upstream that I want to fetch locally?
How can I see a list of changes locally that want to push to the origin or upstream?
Maybe TortoiseGit does not have those; if not: please suggest tools that do.
My answer doesn't directly apply to TortoiseGit, but im sure you will find the equivalent features easily.
Git is a distributed version control system. In order to see the remotes changes, you need to fetch them first:
git fetch
Then you can use git diff to view the differences between your current branch, or even your current (dirty) working directory.
Alternatively you may use git merge --dry-run to see what has to be merged.
To see the things you have changed but not commited (uncommited changes) just type git status.
SourceTree can do this: without the need to fetching, it shows I'm 1 change behind on the upstream remote.
After pulling it, it shows the origin remote is 2 changes behind on master.
my workflow with git is something like this:
1. pull --rebase from origin/master
2. create a new branch for a specific issue and make my changes on that branch
3. switch head back to master and then merge the new branch I've created to to master
from the documentation page, git checkout is suppose to
Updates files in the working tree to match the version in the index or the specified tree
however after I made changes to the new branch and checkout master and check the status using 'git status', the changed files is still present.
Worst of all, I have used the 'undo file changes' option in git extension for visual studio, now that even if I switch back to the branch I created using the 'checkout' command, I no longer see my changes. Is there anyway that I can redo those changes?
Before "checkout master", are you sure you are committing the files in the branch you are working on?
Make sure you commit the files in the branch you are working on. Otherwise, if git discards the changed files, you'll have lost them for ever.
If you do not want to commit the files yet, try looking at git stash. Git stash allows you to temporarily save your changes, without committing them to any branch.