Lets say there exists a MASTER repository with 2 different branches(branch A and branch B) already created for it. I've already cloned master and have a local version of that on my machine. If I pull branch A, checkout to branch B, and do another pull with branch B, do the codes from branch A and branch B get "merged" together? Meaning at since I pulled both of them once already, at any one point in time that I am working on a particular branch, am I working on code that is a combination of both branches? I would not think so. I would think that each branch that I'm working on has its own particular instance and is independent of other branches correct?
If you do the following sequence while in a repository containing two branches A and B, A and B should be independent
git checkout A
git pull MASTER A
git checkout B
git pull MASTER B
However, if you do something like this you'll end up merging A into B
git checkout B
git pull MASTER A
I think this might shed some light on what a branch is and how to do various workflows, as well as a lot of tips/tricks for using Git in general.
http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is
As a best pratice when working with branches, I always set the target branch for a pull.
git checkout branchB
git pull origin branchB
You can if you like pull from branchA and merge with it too
git checkout branchB
git pull origin branchA
Depends in what you want to do. But pulling and merging another branch fron the server blindly is not the best thing to do. In this case you want to fetch look what branchA has to offer and merge after that with git merge or rebase.
Related
Im a bit confused about these scenarios:
I have a task.
I create feature branch, make work here.
And then I create Pull Request to release-test branch.
In order to avoid conflicts, first I have to update my feature branch. So I have to merge release-test into feature.
But in this case, in my Pull Request I will have a lot of merged commits which I don't want to have. I want only my feature branch commits in PR.
What should I do in this situation?
I pushed my feature branch and then conflict appears in PR. What are my next steps?
I tried to revert to the last commit, made compare with release-test branch, then force push. Is this a good practice?
P.S. I'm using Intellij Idea if this would help
In order to avoid conflicts, first I have to update my feature branch. So I have to merge release-test into feature.
Don't: you should always merge from specific to integration branches, not the reverse.
Your feature branch is a specific branch (specific for a given task you are isolating in its own branch)
release-test is an integration branch (where multiple branches come to be merged)
If you need to update your feature branch compared to release-test, rebase it:
cd /path/to/local/repo
git switch feature
git fetch
git rebase origin/release-test
# resolve potential conflict there
git push --force
That will guarantee there won't be any conflict in your PR (automatically updated after the push --force), since your feature branch will only add new commits on top of the most recent remote release-test branch.
I have a dev branch with many changes (files added, deleted...). The dev branch is very different from the main branch.
I want to make my dev branch be exactly the same as the main branch in current state (as if I just created it).
Integrate do not fully match the branches. added files in the dev branch are not being deleted.
What is the best way to do it?
Delete the dev branch and re-create it?
Thanks in advance
Delete the dev branch and re-create it?
If you do this you will probably regret it; Perforce will see that you deleted all those files and try its very best to preserve the apparent intent behind that delete by doing things like propagating the delete back to the mainline at the next opportunity.
The command you want is p4 copy:
p4 copy //depot/main/... //depot/dev/...
or
p4 copy -b dev-branch
(or whatever)
Unless you want the history to be exactly as if you'd just created it. Then:
p4 obliterate -y //depot/dev/...
p4 populate //depot/main/... //depot/dev/...
Can someone please share a code snippet that shows how I can pick out commits on only ONE branch using the JGit API.
If I use RevWalk, I get the entire tree, including sub-branches that have been merged into the specified branch.
How can I get JUST the commits on the specified branch without picking up parent commits of branches that may have been merged into the specified branch?
What may also help is to find out what branch a certain commit is sitting on.
Adding some more info:
How can I get all commits along the develop branch?
So based on the image above, I need SHAs:
2a34
b468
785c
but NOT:
731a
cbdb
Thanks!
In order to traverse the history of a Git repository, starting at a certain branch, you can use the LogCommand as described here: JGit: How to get all commits of a branch? (Without changes to the working directory ...)
The command's addFilter() method can be used to install a RevFilter to exclude certain commits.
I have a long standing patch branch and a develop branch. I want to cherry-pick specific changes from develop to the patch branch.
When I do, I get new commits with no link to the old commit.
Is there a way to cherry pick and maintain the parental link to the branch for that commit?
is adding "-x" the best I can do?
Thanks
Yes, -x is really the only way to reference the commit that you cherry-picked.
If you want to maintain the parent relationship of your commits, you would need to merge the branches. My guess would be that you would want to merge the patch branch with the develop branch so that you keep your work properly segregated.
Though based on the way you phrased the question, I think that you might have a misconception about commits. They don't have a "link" to a branch. Rather each commit has a single parent commit that they point to. Merge commits have multiple parents to show which commits they are merging together. A branch is really just a pointer to a commit. A commit can exist on multiple branches either because it was merged or you created a new branch based from it or a later commit.
What git cherry-pick does is make a copy of the changes that you made on one branch and apply them to a different location. You do this because you don't want the rest of the history coming along with this particular change. If you want to maintain a history, you would git merge or git rebase the changes from one branch to another.
Is theere a way of finding out what changes a bzr update will do without actually doing it.
Specifially I would like to have a bit of warning if there is going to be a conflict.
Not directly that I'm aware of, that's what bzr revert is for. However, there is a common way to structure your local branches to help. I use one local branch that mirrors the central branch, then I branch off of that for my work. When I'm ready to "check in," I update my local mirror branch, which always succeeds without conflicts because I haven't changed my working copy of that branch. Then I merge my feature branch into my local mirror branch, then push my local mirror branch to the central repository.
The advantage of this setup in your case is you could use bzr merge --preview or bzr diff to see the changes if you don't want to actually try the merge. I personally prefer just to revert the merge until the conflicts are fixed either upstream or in my local feature branch.