I just did two commits and they don't show up on master branch, they do in the main project folder, same in Bitbucket repo, it only shows yesterdays commits. I'm not sure how to fix this. If I try to check out to master branch, I get a warning to lighter push or discard changes, but if I push them, they don't appear anywere. I'd appreciate very much a little explanation on how that could have occurred. I'm just starting with version control and I surely messed it up when I checked out on previous commits to check some part of the code, although I thought I did check-out again on last commit.
Many thanks as usual.
I solved it as so:
Selected the latest commit on actual Master branch.
Created a new branch from it and named it anything but Master. That is an exact copy of actual non synchronised Master branch.
Deleted actual Master branch.
Created a new branch from latest commit on newer created branch at point 2 and named it Master.
Deleted branch created at step 2.
Pushed the missing commits to Bitbucket.
Now I have a new Master branch that is in sync with its bucket.
Hope this will help others.
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
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.
OK, I'm new to Mercurial and version control branching in general, so I may have a fundamental misunderstanding of what's going on here -- please be kind... ;)
We are a small development team (2 developers) working on a project, and we have a need to implement a fairly significant change that may take weeks or months. At the same time, the program is in daily use, so we have a need to make regular patches and fixes.
Because of the long-running nature of the significant change, I created a branch off the default branch (call it dev1). I will want to periodically merge the changes from the default branch into the dev1 branch, for reasons that don't need to be reiterated here. However, I do NOT want the changes from dev1 merged into the default branch until much later in the development.
I have tried several different ways to do this, but it always seems the merge affects both branches. After the merge, if I update to the default I now have changes from dev1 merged into the source.
Can I work on both branches using the same repository? If so, can someone please share the sequence of commands to use? If not, it seems to me I would not be able to push the dev1 branch up to the master repo until it was finished, and that just doesn't seem right.
We are running the latest TortoiseHg for Windows, and for the most part I love the graphical tool. However, I am perfectly willing to drop to the command line to do certain tasks when necessary.
Thanks for any help,
Dave
This depends on what sort of branch you've created.
If you have created a named branch, and are working in a single working directory, then you need to use one workflow, but if you have cloned your production repository, you need to use a different workflow.
Named branch workflow, single repo/working directory
In this case, you are using update to switch between the default branch and the dev1 feature branch.
When you want to work on the default branch, update to it, do your bug fixes, and commit those changes. Do not merge in changes from dev1 branch.
When you want to work on your dev1 branch, update to it, merge in your bug fixes from the default branch, work on your feature and commit when done.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes, merge them in and then resume your work (there are shortcuts you can take here, but this way you can backout the merge if it gets messy)
Note: All of these assume that all of your changes are committed at the point you want to switch between dev1 and default branches.
The important thing to note is that you only get the changes from your dev1 branch in default when you merge them in. If you only merge default into dev1 then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple merge operation.
Unnamed branch workflow using dev1 repo cloned from production repo
This workflow is similar, but allows you to work on the default and dev1 branches simultaneously, without having to update to switch between the two.
When you want to work on the default branch, use the repository where the tip is your production code. Do your bug fixes, and commit those changes just as you would normally.
When you want to work on your dev1 branch, use the repository where the tip is your dev1 feature branch. If there have been fixes in the default repository, pull in the changes and merge them into your clone, but do not push the merge changeset back. Only push your changeset back when you want to deploy you feature to production code. Once the changesets from default have been merged in, you can continue working on the feature.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes from your shared repository into your default production clone, then pull those changes down into your dev1 feature clone, merge them in and then resume your work.
Again, the important thing to note is that you only get the changes from your dev1 branch in default when you push them up to your default production repository. If you only pull/merge default changesets into the dev1 clone then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple push operation.
Yes, you can absolutely do this with Mercurial.
First, in case it isn't clear to you (it wasn't to me for some time), there are 3 types of 'branches' in Mercurial:
clone a repository
a 'named branch' (using the hg branch command)
an anonymous branch, which you can manage with bookmarks or just remembering the changeset
I'm guessing that you used the hg branch method. Be aware that this is often not what you want, because that branch name will live in the repo's history forever (well, there is the --close-branch option, but still...).
The essential workflow is:
update to dev branch with hg up devbranch
commit changes to dev branch
merge with main branch via hg merge default or just hg merge as desired
(repeat as desired)
And for working on the default branch:
update to default branch with hg up default
commit changes
(repeat as desired)
Do NOT do this:
update to default branch with hg up default
merge with dev branch with hg merge
I suspect that you are using the command hg merge without specifying a branch name. That will merge with any other head, which may or may not be what you want.
Edit: The above info is probably not your issue. Your issue is probably running a merge when your current branch is the default one.
You don't want to run hg merge from your default branch.
# bang on dev1
# more banging on dev1
# someone beats on default for a while
# update to dev1
hg up dev1
# bring in the changes from default
hg merge -r default
# validate successful merge
hg commit -m "merging"
The key is committing on dev1 when you bring changes over from default.
Note that I'm using named branches here.
This sentence:
After the merge, if I update to the default I now have changes from dev1 merged into the source.
tells me that you're doing something wrong. It is perfectly doable what you want to do, work on two branches in parallel, and merge from one to the other, without influencing both.
It is important to know that the merge is a directional merge. You merge from one branch to the other, and when you initiate the merge, you should be on the to-branch.
directional in the sense that the direction plays a role in the outcome. For the actual contents of the file, it doesn't matter which direction you merge, but the new merge-changeset you commit will be on the branch you was on when you initiated the merge (unless you override.)
So, update to the head of dev1 first, then merge with default, and after committing, you should have a new changeset on the dev1 branch, but default should be left undisturbed.
This is more of a tip than an answer, but...
I use this workflow a lot. I find the Transplant extension very useful for named branch workflows. TortoiseHg supports it, so you can enable it in the TortoiseHg options. It lets you cherry-pick from other branches, which is very useful - especially if you regularly commit to the wrong branch.