When using Mercurial, assume you are using a 'default' branch. You work by creating new branches from this and merging them back into 'default' (when your work on that new branch is finished).
After merging a new branch (call it 'myBranch') back into 'default', you actually decide you need to work on 'myBranch'. 'myBranch' has not since been closed. What is the best to go about working on 'myBranch'?
Merging of branch (in Mercurial) doesn't mean it will become closed|disappeared. Used ranch is permanent part of Mercurial changeset forever
Merge will not close branch, just remove HEAD of merged branch
Because Mercurial's history is DAG, you can always return (hg up CS-ID) to any entry (changeset) in it and start working from this point, adding new child changeset on commit
For named branches, branchname is CS-ID of HEAD of latest (topologically) changeset of this branch
For LTB "Cleanup" I used hg up Cleanup after each merge it to Default branch
Nothing extra to do. If you want to continue from the last commit in myBranch do:
hg checkout myBranch # checks out last commit in myBranch
...hack...
hg commit # creates a new commit on myBranch
If, instead, you want to re-open myBranch with whatever is currently on deafult (rare) you do:
hg checkout default
hg branch --force myBranch # says "next commit should be on branch myBranch and I don't care if there already was one"
...hack...
hg commit
You probably want the first.
Related
I have created a branch from another branch. Then I come back to previous branch and work on it. Now I have switched to second branch. But this second branch don't have the new changes of first branch. I just want to update the second branch from first branch without deleting any of them.
But this second branch don't have the new changes of first branch
Switching to the second branch alone is not enough for said branch to reflect changes committed in the first branch.
You would need to git merge branch1 or, if you are the only one working on branch2: git rebase branch1 (if you want to keep a linear history).
Then, and only then, would you see branch1 changes in branch2.
⇒ The OP Waqar Ahmed proposes in the comments:
I have solved this issue but checking out branch2 and pull the branch1
I'm currently working on an assignment where we work on a local repository and push to a remote repository when we are done. We are expected to make use of branches, wherein we make all our commits before merging it into our master branch, so no commits directly to the master branch.
Everything was going fine, but I've come across a problem when I made some commits on a branch, then merged that branch into my master, before going back to the before-mentioned branch to make some more changes, committing them and merging it once again back into my master branch.
My network tree is currently looking like this:
network branch
The problem being the green branch that is branching off at the end with hash 2bbbd0c.
I'm essentially looking to undo that commit completely and simply have my branch merge into my master, so my network branch shows that nothing is branching off.
One idea I have is to use git reset –hard 2b32611 (which is the hash for my latest commit on the branch before merging it into my master):
enter image description here
And then to use git push -f origin 2b32611:cookies-user-tracking to push the commit and the branch, but once again I’m not sure if that’ll work, and I don’t want to mess anything up.
The git reset --hard will indeed reset cookies-user-tracking to the right commit (before merge)
All you need to do then is to force push the branch:
git push -f origin cookies-user-tracking
I have a mercurial repository on Bitbucket that is forked from another repo. I made several commits to my fork and now want to make pull-request to the main repo.
But I want to include in pull-request only last 2 commits, not all that I have done as Bitbucket offer. Is it possible to do pull-request through Bitbaket, which includes only those commits that I want?
On a pull or push, you can specify a revision, but it necessarily comes with all its ancestors that are not on the repo. If you planned it correctly, and the last two commits are the sole constituents of a separate branch, started from the main trunk, yes, only those 2 commits should be pulled. But from your question, I doubt this is the case.
In Bitbucket, it seems to be possible to request a pull on a branch. So my suggestion is to create another branch, started from the main trunk, and replicate your last 2 commits. There are many ways to do that, but the fastest, albeit not recommended in a normal workflow, but considering your current state, is to graft the 2 commits on that new branch.
hg update default
hg branch <new feature branch>
hg graft -r <commit 1>
hg graft -r <commit 2>
Then, request a pull on <new feature branch>.
I have the branch name default which is my production branch. Now I want to create development branch from there and work separate on it.
How can I do that without affecting my default branch
Commit or shelve all your current changes, then:
hg branch Name_Of_Branch
This will switch your working code to a branch called *Name_Of_Branch* - N.B. this branch will not exist in the local repository until you do a hg commit and will not exist for anybody else until you have done a hg push, (or an accepted pull request to an administrator), and they have done hg pull.
The company that I'm working is working with SVN but I would like to start working with git to take advantage of the light branching and stashing features (disclaimer, I'm pretty new to git). I've started with git-svn and I'm trying to figure out the ideal git-svn workflow for what I'm trying to do (and suggestions if what I'm trying to do needs tweaking).
I've read through git svn workflow - feature branches and merge and a few other posts but its still not clear how I should approach it.
How I plan to work:
I plan on having my master branch be clean from development and only used for merging/rebase/dcommit.
I would like break apart each new feature/bug into separate git branches so they can be worked on independently. Meaning, I can work on one feature for a few hours, then put it aside and work on the next issue. When I was in SVN it was a problem when I had two different features/bugs in one file because when it came time to commit, I would remember that it had both changes and temporarily take out what I didn't want to commit now - a pain.
And the are some features which are while I might want to work on now, will not be added to the main repo for some time.
After a feature is ready to be shared/tested in the main repo, I'll merge/rebase into my master branch and then dcommit to the svn-repo. I only want to have one SVN commit message for each dcommit - I want to be committing in more often with comments more specific to me and then dcommit to svn with a message for the rest of the team. I assume for this I'll either be using a git merge --squash or a git rebase --interactive for this.
The basic git flow I've envisioned is like this:
// it begins...
git svn clone <repo>
//
git checkout -b feature 1
// work commit, work commit
//
git checkout -b bug-123
// work commit, work commit
// bug-123 finished - ready to send back
// got back to master for step 5
git checkout master
// get whatever changes other devs did
git svn rebase
//
git checkout bug-123
// rebase branch so I have fewer smaller changes. not sure here..
git rebase master || git svn rebase
// Assuming I'm doing a FF rebase so my commits are just addons to the current repo
// I don't know if I rebase the master or svn repo or it doesn't matter.
// need to get my changes back to master to send off
git checkout master
// add my changes to master
git rebase bug-123 (--interactive?) || git merge --squash bug-123
// do I add a new commit message here?
// push my changes back out to the team
git dcommit
So there are a few questions:
How should I get the changes into the branch I want to commit - by rebasing the master or the svn branch
how do I get the changes back into the main branch - rebase or merge - remember, I want only one commit for each commit - unless this is going to complicate things - I really would prefer to keep my git commits separate from the SVN commits because I might start something - it's half-working, and want to commit it so I could try something else - but I don't want to commit these broken steps.
would it make sense to dcommit directly from the working branch (eg bug-123)?
how do I get the changes from bug-123 back now into feature-1? I'm assuming I'll do it via the SVN repo - meaning the changes that I added will get merged in when I do the rebase when it's time to add feature-1 to the repo - but maybe not.
I'm no expert, but these are the experiences I've made (related answer).
I think it doesn't matter. The important thing is that you rebase the latest changes from SVN into the branch you are going to dcommit from.
Let other branches receive the changes through SVN. If you want a single SVN commit from a series of git commits, squash them together first.
I think this doesn't matter either. You're going to rebase the latest changes from SVN, and need to get them linearly in front of your Git commits. If you do git svn rebase in master, and then rebase master into a feature branch, or the other way around is same-same. Afterwards you probably want to delete the branch, as it has done its work (as per SVN restrictions, you're not allowed to merge again).
Always let changes flow into other branches and repos through SVN rebasing.
Just try it out and try to get the most simple/practical workflow for you and your team. Try to keep branches short-lived (SVN won't get any notion of them anyway), and remember that the commits must always be linearized at the top of your log before you dcommit back.