Why there is a conflict when I submit a change into a branch on Gerrit, but when I rebase my change onto that branch locally, git can do a fast forward rebase and without any conflict?
The behavior of Gerrit submission is not like git's merge. Why?
Gerrit is very conservative with merges/rebasing. If a file has been modified by your commit has also been modified in the branch you are trying to merge with, Gerrit will fail with a conflict even if git is capable of resolving the conflict automatically. This is just to be extra safe.
In newer versions of Gerrit there is a configuration to turn this safety check off, and have Gerrit trust git's automerge results.
Related
I am new to git so please bear with me. I have a rails application on my local machine that I am experimenting with and pushing to the master branch periodically. It works at the moment, but I have fallen behind, and now I am many commits behind the master.
$ git branch
* master
$ git status
On branch master
Your branch is behind 'origin/master' by 27 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
nothing to commit, working tree clean
However, when I use git pull and then start rails, my application breaks with a precompiler error. So I am forced to use git --reset to go back to the local commit before I used git pull.
What is the right way to get around this issue and merge with the latest changes on the master branch? Would one use git --rebase in this case?
Try
git stash
git pull origin master
And once it updates, git stash apply to reapply your local changes
Since nobody has stated this clearly yet: You ask
What is the right way to get around this issue and merge with the latest changes on the master branch?
When you do git pull that does merge the remote changes into your current branch. Whether you would choose to do a rebase instead of a merge (per your other question) is a separate issue, but the default behavior is to combine the two sets of changes (local and remote).
More precisely, by default git pull does a fetch followed by a merge. The exact merge operation depends on configuration and on command-line options, but in a typical configuration where origin/master is upstream of master, saying
git pull
will merge origin/master into master.
So why the errors?
One possibility is that there were merge conflicts. If that happens, git will tell you. If you say git status in this condition, it will tell you that there's a merge in progress and it will indicate which paths (files) need conflict resolution.
Another possibility is that the changes don't conflict (in that they don't affect the same region of the same file) but still don't work properly together. That you would simply have to debug.
I am working on a completely different structure from the one on master branch, on a On Rails app in a local branch. I am comiting everything and then pushing my changes to a remote branch as well. At some point in future, I would like to integrate my changes back into master, but I want to make it even first, so I won't be behind it, just ahead by n commits. If I am doing a
git pull origin master
into my branch and then push that, would I loose anything from my previous commits, or would those stay on top of the master branch ones? In theory I should be able to merge my branch, as I will only be ahead of master, but I am not entirely sure if that's how git is working
Never do significant work on the master branch. The only time you are really working on the master branch is when you are merging or if you are the lone programmer on a project (even then its questionable).
When working on a feature or taking care of a bug you want to be working on a separate branch.
For example when I take an issue from the product tracker I create a topical branch based on the name of the issue:
git checkout -b 136-fix-something-important
If the work on a topical branch takes a long time you keep up to date with the remote by pulling the changes into the master branch and rebasing your topical branch off master.
git status # make sure you have a clean slate otherwise stash or commit
git checkout master
git pull
git checkout 136-fix-something-important
git rebase master
This would fast-forward 136-fix-something-important if there are no conflicts or you would have to resolve the conflicts. However taking care of conflicts is better done early that later in a mega merge.
When you are done with the feature in your topical branch you either merge it (if you are a maintainer) or send a pull request (if you are a contributor).
So what do I do now?
Move your work to a separate branch. And reset your local master branch from origin/master:
git branch mybranchname
git reset --hard origin/master
git checkout mybranchname
You can the rebase your work in mybranchname off master.
git rebase master
Other answers aren't wrong, but it would be cleanest to push to a remote branch, pull to local master from remote master, then locally merge master into your local feature branch.
Then, your changes wouldn't be lost, merge conflicts could easily be resolved, and you won't rewrite any other potentially collaborative history with rebase.
you will not lose data when you do a PULL but you will get merge issues which you will need to fix.
While technically you can push without pulling (with --force flag), you should not do that, because it discards other people's work. First pull their changes, resolve conflicts and only then you can push.
Piece of advice, try to make your units of work small, as in don't spend too much time away from master especially if master gets updated frequently. The reason is that you will have a very difficult time merging.
In JIRA connected with STASH you can create a feature branch for an issue using the button 'create branch'. (That is nice to track the commits in this issue.)
If a developer started working but did not know that there is such an issue he did not click the 'create branch'.
Is there any possibility to assign an existing git branch to an issue?
ex-Stash developer here.
Yes and no. Creating the branch though the UI is just a convenience. The important thing is that the name contains the JIRA key. If only one developer is working on the branch, it's fairly easy to just rename (delete + add) a branch with the appropriate name.
git checkout old-branch
git push -u origin old-branch:JIRAKEY-1234-something
git push origin :old-branch
Does that help?
Update
As for january 2017 if you have an already exiting branch and you want to attach it to a Jira Issue you can do the following:
Checkout to the branch you want to rename
Execute the following command
git branch -m JIRA_ISSUE_ID-Whatever
Assuming that mine Jira issue is SO-01 I can do the following:
git branch -m SO-01-Whatever
This will change the name locally, push it to remote with:
git push origin :old_name
Command Syntax
git branch (-m | -M) [<oldbranch>] <newbranch>
Related question for more info
This is no longer the case. With a common setup between bitbucket and Jira, simply including the issue ID in the commit message will create a link between the commit, and thus the branch, and the issue in Jira.
I just tested the theory that having the Jira ID in the branch name creates an automatic link.
It does.
To see the effect, you have to push a commit. Then the branch will show up in the Jira.
The branch shows up in Jira, but to get an individual commit to show up in Jira I have to refer to the Jira ID in the commit message.
The web interface option is to branch off a branch but merge back to master in the pull request.
eg:
click create branch in jira
set the repo, branch type and name to what you want
set the branch from to be the existing branch
click create
when creating a pull request set the destination branch to what you want eg master
If you include the JIRA-ID in the branch name, by creating out of an existing commit, all you have to do is:
git push --set-upstream origin <new-branch-name>
and the branch is attached to the JIRA ticket.
Just add a new commit with the Jira issue key in the commit message
I have a branch named development. For some reason, every time I switch to development and try to merge into another, Xcode is creating a new branch titled development1, development2, development3, etc etc. I am not sure why this is happening or how to stop it.
It left me in an unfortunate situation. We have a billion branches on the project now. Any ideas?
I'm just trying to switch and merge. This is making a mess of the project. I'm not sure how to handle it.
Sounds like a potential bug in Xcode. I recommend just using the command line:
To switch to another branch:
git checkout branch_name
To delete a branch:
git checkout -d branch_name
To force delete a branch (if commits on a branch are not on any other branch):
git checkout -D branch_name
To merge with another branch
git checkout branch_to_change
git merge branch_to_merge_into_current_branch
I was switching to the remote branches. Every time I did that, it created a new branch locally. This could be considered an Xcode bug, but I have a feeling I was simply misusing Git. I'm just picking it up.
We are using Jenkins,GerritTrigger setup for CI and it will start build for each commit though all commits came from single push. Since all changes are dependent on each other its enough to make a single build with all changes, but I don't see that option in GerritTrigger plugin.
I believe many companies use Jenkins and Gerrit combination and I am curious to know how they are handling these cases.
Example:
If a developer pushes below 4 commits at once to gerrit it will create 4 changes accordingly in gerrit say 1,2,3,4 and it starts 4 builds in jenkins for all commit
git log --oneline
e3dfdwd CommitD
5fgfdgh CommitC
df34dsf CommitB
a23sdr3 CommitA
Here 4 commits as a whole will pass all tests in jenkins but individually they will fail. Now jenkins builds will fail for A, B, C and will succeed for D as it will checkout A,B,C as they are its dependencies.
In this case though Commit-D is successful it can't be merged as its dependencies are not passed in Jenkins.
It seems reasonable from development to expect jenkins verification for each push instead of each commit. But GerritTrigger can run for each commit only.
Question:
Is there a way to inform jenkins to start build only for commit-D as it will have all dependencies C,B,A ??
Or can we start a build for each git push from development instead of commits?
Sorry if I had any info
I found a way to start build only for commit-D.
I have introduced a gerrittrigger job which runs immediately after every commit, this job will not do any clone/build/verification.
It will just do some set of verifications like, check if given change has needed-by change, dependency exists and dependencies on same branch etc
This job will trigger another main job which does real clone, checkout change, build, verification etc only for changes which pass all validations.
So this will start job always for top commit and approve/reject all dependent changes based on job result.
Though it has few limitations, we found this method is suitable for our workflow
Most companies don't use git and gerrit :) Most companies don't even use git, unfortunately. And most of the ones that do, don't use gerrit. I've consulted for dozens of companies: two use git, and neither of them have even heard of gerrit.
I don't think it's possible to get gerrit to think of pushes as if they were commits. Since each commit in a push can be separately reviewed and rejected, each commit has to be considered and built separately. If you don't want it to work that way, gerrit might not be for you.
Instead, you should squash your related commits locally before pushing them to gerrit. This will achieve the desired results.