I have two branches in Github. Master and CoolFeature.
When i check CoolFeature in Github i see that it is even with Master.
When i deploy through Team City the Master branch somehow i get a commit from the Master branch that is five commits behind. I can see it in Team City by checking the SHA1. Is there some feature i have missed?
When i deploy the CoolFeature branch then the latest changes works cause CoolFeature deploys the latest commit.
Edit:
When i checkout the master branch i get this message:
> git checkout origin/master
Note: checking out 'origin/master'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at e86824af5...
The SHA1 hash refered e86824af5... IS the latest commit. And this is the one i want to be deployed. But TeamCity deploys a commit that is five commits behind this one. I can see it in the log comparing the SH1 hash ids.
Related
Been using production/integration branches to manage code promo to production. Our integration branch is a stable integration environment that all feature branches are made from, and merges are reviewed by PR, and deployed via CI when approved and squashed+merged. Once integration is stable and we've tested it, we do another PR from integration to production. When this is approved and squashed+merged, CI takes over and deploys to the production env.
git checkout integration
git checkout -b feature
# do work
git add/commit etc
# create PR, squash+merge on github UI when reviewed
# CI sees new commit to integration, deploys to int env
My issue is with what these integration -> production PRs looks like when they are reviewed - even though (at times) I've done the following to get any commits already in production into integration:
git checkout integration
git pull
git pull origin production
git push
# create PR for integration merge into production
When I go look at the PR page on Github, the list of commits shows history going back to commits that are already represented in production. The "Files changed" list is very small, while the commit history goes back many PRs ago. I thought git pull origin production would remove this history and then only show the new commits coming from integration to production?
Am I missing some obvious way to maintain merge commits but also clean up the history when integration is merged into production? Could inconsistent merging/rebasing strategies cause this?
Some screenshots to show what is confusing - a PR that has a single file changed from a single commit, but the commit history goes back much further:
The single file change was the last commit in the list—why does the PR show commits that have already been merged previously? I thought Squashing and Merging (both into integration from feature branches and into master from integration would remove this commit history and make merges into master clean?
The green arrow represents the 1 file changed in this PR, and I thought the commit history (after a merge of production back into integration to clean the history, if any) would only have that one commit.
Is this a github display bug or am I missing some principle of how git maintains commit history across a long-running branch that gets merged into another long running branch? It's always a one-way merge, from integration into production branch, for CI to deploy the update.
The normal GitHub flow to contribute to a repo is to create a fork of the upstream, clone a local copy where you make changes, then push back up to your fork and then create a PR to have your changes merged into upstream.
But if upstream changes after that, how do you update your fork without creating a merge commit (and also without using the git CLI)?
I already know how to do this in a way that will create a merge commit or which depend on the git command line interface. This question is specifically about using the GitHub.com website or GitHub Desktop application only (no CLI).
Since this is a very common workflow it seems like there should be some simple way to do it using the GitHub GUI.
To reiterate: any answers that use the CLI or create a merge commit (e.g. this way) will not be answering this question since I'm explicitly looking for a non-CLI solution.
without a merge commit or using CLI?
Not directly with GitHub web UI alone, since it would involve rebasing your PR branch on top of upstream/master
So in short: no.
But in less short... maybe, if you really want to try it.
Rebasing through GitHub web UI is actually possible, since Sept. 2016, ...
if you are the maintainer of the original repo, wanting to integrate a PR branch
if none of the replayed commit introduces a conflict
(This differs from GitHub Desktop, which, since June 5th 2019 does support rebasing. But that is a frontend to Git CLI, like other tools provide. For example GitKraken and interactive rebase)
So a convoluted workaround would be:
to fetch, then push upstream/master to the master branch of your own fork (a CLI operation, but more on that below)
change the base branch of your current PR to master (so a PR within the same repository: your own fork), provided you haven't pushed to master.
Meaning: master in your fork represents the updated upstream/master, with upstream being the original repository that you have forked.
Since you are the owner of that repository (your fork), GitHub can then show you if you can rebase said branch to the base branch of the PR (master), but only if there is no conflict.
finally, change the base branch again, to <originalRepo>/master (which is the intended target of your PR)
The very first step is typically done through command line, but... there might be a trick to do it (update upstream master in your fork) through web UI: see "Quick Tip: Sync a Fork with the Original via GitHub’s Web UI" by Bruno Skvorc
In short, it involves:
creating a new branch from your current master (which would be at upstream/master at the time you forked the original repository)
Making a PR with that new branch and <originalRepo/master>
doing a base switch before creating the PR
That is the step which artificially forces upstream/master to be refreshed
You can the create and merge it with the “Merge Pull Request” button (and “Confirm Merge” afterwards): the merge will be trivial: no merge commit.
The end result is: your own master branch (in your fork) updated with upstream/master (the master branch of the original repository)!
You can then resume the steps I describe above, and change the base of your current PR to your own (now refreshed) master branch, and see if you can rebase it!
This is feasible with GitHub Desktop since version 1.0.7 considering the following:
If the current branch does not have any commits ahead upstream (the original repo of the fork), the new commits can be pulled without creating a new merge commit
In GitHub Desktop:
Clone your repository from File > Clone Repository
Fetch origin, which will automatically fetch the upstream as well
Go to Branches by clicking on where it says Current Branch
Click on Choose a branch to merge into <branch> at the bottom
Search for upstream/<branch>, then click Merge upstream/<branch> into <branch>
Push to origin, et voilà!
Otherwise, ff the current branch has commits ahead of the fork, then of course one has to create a merge commit or rebase and force push. For rebasing which might be more preferable, do the following:
In GItHub Desktop, go to Branch from menu, then Rebase Current Branch
Search for upstream/<branch>, then click Start Rebase
Solve any conflicts that have occurred from the rebase
Force push to origin. You will get a warning for this for obvious reasons.
For avoiding force-pushing to your work when your current branch is both ahead and behind its upstream counterpart, either create a new merge commit or:
Make a new branch based with all your changes
If needed, reset the original branch to its original state (before it diverged from the original repo)
Perform the steps from the first scenario and merge your changes into your branch.
And yes, it seems that pulling via the GitHub website from the original repo without creating a pull request and merge commit is not possible at this moment.
Demo GIF for first scenario: https://imgur.com/a/8wci2yf
Some GitHub issues related to this:
Add an upstream to forked repositories
multi-remote support in Desktop
Update
Note: Non-CLI based approach that might help:
Is there a way to make GitHub Desktop rebase a branch against master?
The only key here is doing a rebase, so the above answer should help.
CLI way (which is easier and using git, so it should be more comprehensive by default)
There are some practices that you should use to avoid this.
Don't work on the master branch in your fork.
$ git clone <your fork>
$ git checkout -b feature_branch
You can work in your feature_branch and then raise a Pull Request.
Once your changes are merged in the upstream master, you can pull from upstream to your origin. Since the master on upstream will have your commits sitting neatly on top of it, there won't be a merge commit.
$ git checkout master
$ git pull upstream master
$ git push origin master
In the case, where the maintainer has diverged from the master that you have in your fork, that is, it's not linear any more, you need to pull a fresh copy of it. That should not be a problem as your changes are already in the upstream.
If the master in upstream has moved ahead while you were working on your PR, then you can rebase on you feature_branch.
$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master
Please refer to this document for detailed reference: Fork and pull request workflow
I'm new to Github and I have a branch that I want to merge with the master. I couldn't merge it via git command line, its very complicated.
I tried to merge it on Github site following below documentation:
Merging a pull request on GitHub
But I got the following message:
There isn’t anything to compare!
Here's the project:
https://github.com/SumayahAlharbi/erecords
What does 4 commits behind master mean?
Update
Please check below pictures:
I thought I did the merging successfully but nothing changes!
What does 4 commits behind master mean?
It means that the master branch has 4 commits which are not present in your branch currently. You need to rebase your branch and then create a New Pull
Request which will be needed to be reviewed and finally approved so
that your branch can be merged with the master.
There isn’t anything to compare!
Check the difference between the master and your branch. Click the Compare icon in Git hub or run this
command from your local branch in Git Bash : git diff --name-only master_branch.
I just checked your repo. The changes of ExportFeature branch are already merged into the master branch, and then the merge is reverted. That's why now if you raise a pull request to merge ExportFeature into master, you would get There isn’t anything to compare!.
See the latest commits on ExportFeature which are already present in the master branch.
The reason you are seeing 4 commits behind master on ExportFeature branch is since the master branch has 4 more commits than the ExportFeature branch. If you see the total commits on ExportFeature branch, it's 7, whereas the total number of commits on the master branch is 11. If you need to do any more changes on the ExportFeature branch, you would need to get the latest changes from the master branch by running the command git pull origin master when your current branch is ExportFeature on your local git terminal.
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.
Consider two repositories, production and stage. I have a branch in production repository called stage-branch. What I am trying to achieve is to merge latest changes from stage repository into that branch.
And everything went well, I cloned my production repository I pulled stage repository and merged under stage-branch.
What is unexpected though is that the default branch in my production repository now has been replaced by the default branch of the stage repository, which was not intended. I have just committed my merge changes under stage-branch in production repository but when I push I get a notification that there is a new head in my default branch.
How can I keep or revert my default branch to the state it was before pulling and merging?
EDIT: Production repository is a fork of stage repository, is it logical that the tip is getting automatically to latest revision of the pulled repository?
When your push or pull something in Mercurial, by default everything (and not just the current active branch, as it is in e.g. Git) will be pushed/pulled. If you would only like to push or pull a specific branch, you'll have to use the -b option.
From hg help pull you'll for instance see:
-b --branch BRANCH [+] a specific branch you would like to push
So if I understand your problem correct, it sounds like you doing a hg pull -b stage-branch should be the right thing to do.