When using Gitlab or Github to manage code, after merged a merge request or pull request for dev to master, the HEAD of dev always fall behind HEAD of master one commit because of the default merge command is git merge with --no-ff.
How to make HEAD of dev to be the same as HEAD of master?
I find some command online:
git checkout dev
git merge master --ff-only
Is it right? Is it reasonable to merge master into dev?
You should never merge public branch into your own feature branch.
Try git rebase master
Related
is there a git svn command that will tell me the HEAD revision on the svn remote repositiory before I perform a git svn fetch?
Use case (Since someone asked why I'd want to do this.)
I want to check if there has been a large number of commits to the remote repository before I start the fetch, so I know whether to do something else* before it finishes, or just sit staring at the console because it will be done quickly.
* something else = go and make a coffee
Git has a similar feature with git ls-remote.
git svn itself might, through git svn info <url>, which does an svn info (without -r/-revision option support though)
Try using it with the URL of the remote SVN repository.
If it does now work, try svn info <url> directly.
I'm trying to tag the git repo of a ruby gem in a Bamboo build. I thought doing something like this in ruby would do the job
`git tag v#{current_version}`
`git push --tags`
But the problem is that the repo does not have the origin. somehow Bamboo is getting rid of the origin
Any clue?
Yes, if you navigate to the job workspace, you will find that Bamboo does not do a straightforward git clone "under the hood", and the the remote is set to an internal file path.
Fortunately, Bamboo does store the original repository URL as ${bamboo.repository.git.repositoryUrl}, so all you need to do is set a remote pointing back at the original and push to there. This is what I've been using with both basic Git repositories and Stash, creating a tag based on the build number.
git tag -f -a ${bamboo.buildNumber} -m "${bamboo.planName} build number ${bamboo.buildNumber} passed automated acceptance testing." ${bamboo.planRepository.revision}
git remote add central ${bamboo.planRepository.repositoryUrl}
git push central ${bamboo.buildNumber}
git ls-remote --exit-code --tags central ${bamboo.buildNumber}
The final line is simply to cause the task to fail if the newly created tag cannot be read back.
EDIT: Do not be tempted to use the variable ${bamboo.repository.git.repositoryUrl}, as this will not necessarily point to the repo checked out in your job.
Also bear in mind that if you're checking out from multiple sources, ${bamboo.planRepository.repositoryUrl} points to the first repo in your "Source Code Checkout" task. The more specific URLs are referenced via:
${bamboo.planRepository.1.repositoryUrl}
${bamboo.planRepository.2.repositoryUrl}
...
and so on.
I know this is an old thread, however, I thought of adding this info.
From Bamboo version 6.7 onwards, it has the Git repository tagging feature Repository Tag.
You can add a repository tagging task to the job and the Bamboo variable as tag name.
You must have Bamboo-Bitbucket integrated via the application link.
It seems that after a checkout by the bamboo agent, the remote repository url for origin is set as file://nothing
[remote "origin"]
url = file://nothing
fetch = +refs/heads/*:refs/remotes/origin/*
That's why we can either update the url using git remote set-url or in my case I just created a new alias so it does not break the existing behavior. There must be a good reason why it is set this way.
[remote "build-origin"]
url = <remote url>
fetch = +refs/heads/*:refs/remotes/build-origin/*
I also noticed that using ${bamboo.planRepository.<position>.repositoryUrl} did not work for me since it was defined in my plan as https. Switching to ssh worked.
I worked on a branch in my Rails app, committed, and merged it into my master, because I was happy with everything, but now I want to take out that branch again and discard those changes.
Is it possible or too late now that I have merged the branch with the master?
Thanks
Once you have pushed commits to a central location, it's best not to modify them in any way.
An alternative is to generate a reverse commit. That is, a commit that undoes all the changes in a previous commit. One way is git-revert. Assuming that you've merged in commits <sha2>, <sha3> and <sha4>, you could:
git revert <sha4>
git revert <sha3>
git revert <sha2>
If you'd like to revert all changes in a single commit, try the --no-commit option:
git revert --no-commit <sha4>
git revert --no-commit <sha3>
git revert --no-commit <sha2>
git commit -m "Undid feature merge"
Another way to generate a single reverse commit is git checkout:
git checkout -f <sha2>
git commit -a -m "Undid feature merge"
You could do a git reset. This is fine if it was only a recent local merge.
If you already pushed the merge somewhere or you have more commits on top, this is no good idea. Instead you have to accept your merge and do a clean git revert. This way the history still contains the merge but the revert will undo the effect of the merge.
When I sync from the ToolTwist Designer, I select the files I wish to publish, but I get an error when I press OK, saying that the sync failed and to look in the server log file.
If I try again, the files I selected are no longer in the list, but if I check Git I can see they are not pushed to the repository.
In the log file I see that the push failed, and if I go to the webdesign directory and test the push command I get the same error:
$ git push --dry-run
To git#github.com:MyRepository/design-project.git
! [rejected] master -> master (non-fast-forward)
I'm using the 'design' branch, so I'm not sure why an error is occurring on the 'master' branch.
In normal circumstances the Designer only uses a single git branch, normally named 'design'. The error message above indicates a conflict on the master branch.
It appears that changes have been committed to the master branch on the local machine but not pushed, whilst elsewhere changes have been committed to the master branch and have been pushed onto the remote repo.
To clear this conflict you'll need to checkout the master branch and do a pull to merge in the changes on the remote, and then the next push will work. Don't forget to change back to the design branch when you're finished.
[stop the Designer]
$ git checkout master
$ git pull
[resolve any conflicts]
$ git push origin master
$ git checkout design
[start the Designer]
By default git tries to push commits on all branches. In this case, you might find that the conflict on the master branch is preventing your web design changes on the design branch from being committed. To prevent this from happening, you can configure git's default behaviour to only push the current branch.
$ git config push.default current
You might also want to investigate why the master branch is being changed (and in two locations).
In my project , i have local branch for working and branch on network drive
i did "bind branch" between local one and network one
My idea is to use the bind option for auto backup of each local commit.
After i commit files in the local branch , i receive a message in network branch
" Working tree is out of date, please run 'bzr update'."
my question is :
Log on network branch will show the updated tree . Does the files are updated ? or i must do "update" ?
automirror plugin will help me for this scenario?
thanks
Binding a local branch to a remote branch means that commits to the local branch will automatically push that commit to the remote branch. If the remote branch and the local branch are not in sync, the commit will fail and neither the local or remote branch will be affected and your changes will still be sitting in your working tree. To get your local branch in sync with the remote branch, use bzr update.
If your network branch has a working tree, then the working tree is not automatically updated when commits are pushed from the local branch into the network branch. The network branch's working tree has to be updated with bzr update or plugins like automirror or push-and-update.
Unless you actually need the working tree in the network branch, I would recommend that you reconfigure the branch to be tree-less using bzr reconfigure --branch. If you have a shared repository that the network branch belongs to, you will also need to use bzr reconfigure --with-no-trees on the repository to stop it creating trees on new branches.
The 'bind branch' feature will succeed only if your local and network branches are up-to-date.
So the commit failed as there is a difference between these 2 working copies.