I am trying to get the hang of merging branches with the GitHub for Mac GUI. I'm not sure if it's me or the client at this point....
I have a repo with master, staging, production branches. I created a file in master called test.txt. I then added a test line to it. I committed and synced in the master. I merged from master to staging using the gui, then hit merge. I also re-clicked "branches in sync" to re-sync them. The new line shows up in GitHub under master, but not under staging. In my local repo, it shows both in sync with that latest commit.
My plan was to edit in master, merge to staging to deploy and test, rinse, lather & repeat until it's good, then merge to production (at this point all should be in sync).
Am I doing something wrong?
That looks like GitHub for Mac issue 3:
Merging branches does not recognize new changes to sync
It seems that when merging the receiving branch does not recognize that new changes can be synced with Github
Steps performed
add and checkout "experimental" branch
add/commit to experimental branch
merge experimental branch into master
master displays button "Branch in Sync" even though it is no longer in sync - pressing button does nothing
How to fix
add a new commit directly in master
"Sync Branch" appears and can sync to Github
The OP skinnygeek1010 reports:
I've found a nice workaround:
To merge master with staging, merge with the GUI.
When it's finished, switch to staging and then go to the drop down menu: Repository > Synchronize (Cmd S).
The merge will instantly show up on GitHub (won't work if you Sync in master though)
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.
What is the correct way to merge two branches of a Github project with Pycharm?
Suppose there is a branch in a Github project called master and I clone the repo with Pycharm. After that, I create a new branch dev by using Pycharm. The new branch is then shown correctly on Github and some commits are made to the branch.
Now, I want to merge the changes from the dev branch to the master branch.
For ordinary git (not Github) projects, I would checkout to the local master in Pycharm, click on dev in the local branch and select the merge context menu. As a result, dev would be merged to master such that it can be safely deleted.Though, even after I merge the local master with the remote master branch, no changes are shown on Github and both branches still exist.
I also tried to close Pycharm, do a pull request on Github, merge the branches there and restart Pycharm. Unfortunately, Pycharm doesn't even recognize that the remote dev branch has been deleted.
My subpar solution has been as follows:
Pycharm: Merge local dev to local master, delete local dev, merge local
master with remote master
Github: Create PR, merge branches, delete dev
Pycharm: Delete remote dev
Now, if I rebase onto the remote master in Pycharm, I get the correct merged branch. Unfortunately though, using the compare context menu, Pycharm still shows that the remote master compared to the local master doesn't have the commits from dev. Although a rebase from the remote master contains all the commits from dev...
Sadly, there's also no Pycharm manual for merging branches with Github (for normal git there is). Any idea?
The solution is to manually push your branch merge as it seems that pycharm doesn't do this, but it thinks it has.
I've noticed the same issue and it seems that the merge is not pushed from the local copy. In a command shell I checkout the master branch of my project and it tells me that I am ahead of online repository, so to resolve this I issue the git push command and then when I check github it has been uploaded.
(tf36) E:\git\alpha-zero-theputernerd>git checkout master
Already on 'master'
A src/alpha_zero/env/env_inherit_from.py
Your branch is ahead of 'origin/master' by 3 commits.
(use "git push" to publish your local commits)
(tf36) E:\git\alpha-zero-theputernerd>git push
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/theputernerd/alpha-zero-theputernerd.git
bb60325..37c3c9d master -> master
I am quite new with Gitlab and I'm having an issue for merging in Eclipse.
We're working as a team, and we all have development branches that we are trying to merge into a single one. Unfortunately, when I did my merge, I have done a stupid mistake. Instead of merging my development branch to the main one, I have merged the main one into my development branch.
I have reversed the commit/merge on gitlab, but now as I try to merge back my development branch into the main one on Eclipse, it seems like I am 9 commits ahead of this branch (described as the arrows on Eclipse here: ), so the potential merge would basically replace everything by my code, when I should actually have merge conflicts to solve.
I am not quite sure how to merge properly so that I get back these merge conflicts.
Here is a screenshot of my network:
The ['1'] commit in the network on the left branch (my branch) corresponds to the merge from Week6AllIssues to my dev branch (the wrong merge). The last commit on this left branch is me reversing the commit.
Thanks a lot for your help !
If you're not using the remote branch with anyone else, the following series of steps might help.
First, remove the superfluous commits from the local branch. It can be achieved with git reset --hard <the commit before you merged master into your branch> command (see this link on how to do this with Eclipse).
Now make the remote branch match your local branch. You can do this with git push --force command. In Eclipse, this command corresponds to configure push - enable "force update" option.
Now the superfluous commits are gone.
We have a Master branch and a Develop branch for our repo. We are supposed to check-in (commit, push) to our Develop branch and then merge that with our Master branch. Then a build is run for the Master branch. I pushed my changes directly to Master (then tagged it), putting Master multiple commits ahead of Develop and now want to bring Develop in sync with Master. What is the best practice to do this? I use GitExtensions and Visual Studio 2015 (am ok doing the operation in either). Do I 'push' Master into Develop or do a check out of remote branch Master and merge with my local?
I would find it most clear to just check out both branches locally, merge in the changes from your local master to your local develop. Then push your local develop to remote.
The workflow I use works something like this in the scenario you describe:
Switch to Develop branch
Fetch All
Choose last (newest) commit in Master, right click => Rebase current branch on => (commit ID)
If Rebase works successfully you're done. If not, you may need to resolve conflicts or cancel the Rebase and merge from scratch.
The reason for using Rebase is that it maintains a single line of commits thus helping keep everything clear.
For more info on the difference between rebase and merge see:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
I'm using Egit on Eclipse Mac and PC to sync a project that has three branches:
master
dev
rendersystem
I've created the project on the Mac and when I created the two branches dev and rendersystem I've used revs/heads/master as the Source ref and as Pull strategy I've used Merge.
Now I've switched to my PC and imported the project with Egit incl. all three branches. But if I change to dev or rendersystem branch it tells me that these branches are remotely tracked (in Branches dialog, Remote Tracking /origin/dev and /orginin/rendersystem).
If I check out dev or rendersystem branch and change my code, then commit it and try to push it to Github, it doesn't push the dev or rendersystem branches, only the master it pushed.
My question is now: How do I change the dev and rendersystem branches so that they are in a state where I can push them to Github from my Mac and PC?
Sorry if this question sounds confusing, but Git is one hell of confusing for beginners.
Remote tracking branches are read-only in git, as they represent remote changes. A Fetch will only update these remote tracking branches. A Pull first executes a Fetch, and then merges the changes with a locally editable branch.
On the source computer there was no need to create this branch, as it was initialized locally, and pushing the branch can create the remote branch.
You can create a local branch from the remote branches by Right clicking on the Remote branch in the Git Repositories view, and selecting Create branch... After that, your branch would be writable.