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.
Related
I am working on a project, using Fossil for version controlling and organizing it. I have some branches other than my main trunk branch, and want to update (commit) only a single branch. Doing commit will push my changes on a branch to the main Files (i am hosting my project on Chiselapp)
. How is it possible to update or commit only a single branch without affecting the main files?
A commit only ever affects a single branch. Except perhaps after merging two branches, but I'm assuming you haven't been doing that.
The only thing I can think of is that the skin you're using has a "Files" menu item that links to dir?ci=tip. The tip is a special name for the most recent commit. Which means that, if you make a commit in a different branch than trunk, that "Files" menu item will now show you the files of that other branch.
The hackish temporary way to fix that is to make a commit in trunk afterwards, so that tip refers to trunk again. But that's not ideal.
The easiest way to permanently fix this, is by choosing a different skin which doesn't do that, or by editing your skin's header, and replacing the link to dir?ci=tip by another link, dir?ci=trunk for example. That way, that menu item will always show the files in the trunk branch.
Fossil unlike Git pushes/pulls all branches and tags at once*. The reason (apart from being by design) is that Fossil repository is a database, push/full synchronizes the database in the respective direction.
This means if you committed changes on several branches then all of them will be pushed to the remote.
*UNLESS, the changes are done on private branches (see fossil help for fossil commit --branch --private, fossil branch new --private).
Private commits/branches by default are excluded from push/pull. To also include these use --private option (see fossil help for fossil push --private).
Once the changes have been pushed, they are integrated in the remote repo and can be viewed in the remote repo's web-GUI as individual commits or via the branch to which they belong. The view includes the Files section that reflects the repo contents (snapshot) at the commit's version.
To answer your question: if you committed changes to existing trunk branch, they will be pushed to the remote trunk as well. If you don't want to make changes to the remote trunk, then make your changes in your new branch (to be pushed as a new branch) or in your private branch (will NOT be pushed by default).
My colleague created a feature branch about a year ago and checked in some modification on it. Now I need to continue with it but During the time files was changed on the main branch too.
Now I need to rebase feature branch to main latest and merge changes from main to my feature branch.
How can I do that?
cleartool rebase is a term from UCM ClearCase, and applies to a baseline (a label on all elements of an UCM component -- or set of files).
If you are not using UCM, the equivalent would be to put a label on the LATEST of the elements in your branch.
In both cases (UCM or non-UCM), the end-result of that rebase would be to merge the main branch into the feature branch.
In non-UCM, this is a simple cleartool merge (you don't need the initial LABEL: it is just to memorize the state of the feature branch before the merge)
Warning: that "rebase" is not like a rebase in a distributed VCS like Git, where commits (versioned set of files) are replayed. Here, ClearCase is file-centric, which means it will only do merges.
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.