As of the latest version of Github for Windows (1.0.24), I began having issues merging and syncing repos. I have an enterprise github account.
Here is an example situation, I merge my develop branch into the master, but the commit does not display when viewing the master branch in GFW. Therefore the sync option is not available because GFW believes the code on the local repo and server are in sync.
When I look at the master branch source code, I see the the latest commits from the develop branch that were merged into it are there. GFW does not display any commits EXCEPT when you use the Manage branch option. There you can see the lastest commit is the in the master branch.
Something is out of whack, maybe its me!
Any thoughts?
Yep, I get the exact same thing from time to time - you're not crazy.
I wish they'd fix it though
Related
I have a fork of microsoft/vscode-arduino on github. Some time ago I submitted a PR that was accepted. Time passed and now I want to do some more work.
At the time my use of git and github weren't very sophisticated and I rather foolishly did all the work on master.
On my local repo I pulled from upstream master, merged and committed to my fork, and was surprised to find that github thinks my fork is still 7 commits ahead and 113 behind.
Then I tried to rebase on the upstream as described on this page My pull request has been merged, what to do next? but the command
git pull --rebase origin master
and after a bit of mucking about I'm no commits behind and 12 commits ahead.
I really don't care about preserving anything. Everything important has long since been merged into the upstream repo. I just want to make this main exactly the same as current main in the upstream, so I can branch for my new efforts fixing an ongoing problem where every time there's a release of VS Code that uses a different version of node it breaks the serial port native integration until the Arduino extension is updated to the same release of Node and released.
Can anyone advise on how to do that? (discard the 12 commits ahead, not the N-API thing)
This may not be the most elegant but it worked.
Use GitLens in VS Code to find the oldest commit that isn't mine and do a hard reset to that.
In the terminal pane, git push --force. Refreshing the github page it now says I'm two commits behind origin (the repo I forked). I'm rid of the unwanted commits. Now to work forward.
In VS Code terminal pane git pull --rebase upstream master
In VS Code click on the status bar to sync.
Refresh the github web page. Hooray, This branch is even with microsoft:master.
Hi I'm using source tree with github for unity as an inexperienced user and have made a big mess. Basically I was making changes to a game in the master branch in a higher version of unity 2019.3 and decided to then revert back to a older version of unity earlier in the master branch.
I then created a new branch and started making new game changes in unity 2018.4. I have decided that I want to keep with unity 2018.4 but the problem I have now is that my master branch is behind and has different changes and in a totally different version of unity. I went to merge and resolve conflicts using theirs to keep changes for the 2018.4 branch but it has left a huge mess.
All I want to do is possible is to delete/remove all the changes I made in the master branch in unity 2019 and just make the top of the 2018 branch become the master so I can continue with that as the master branch.
Is this possible to do if so how, I hope my explanation made sense.
Sounds like you'll need to use rebase to remove the 2019 commits from master. Then you should be able to just merge into master.
Try this
Rebase master, drop bad commits, merge branch.
Should be run git rebase -i master replace the "bad" commits keyword with drop. You'll likely want to specify how many commits to edit, this can be relative like HEAD^x or a SHA of the last "good" commit. Then fix and merge conflicts and merge the second branch with git merge branchname.
You might want to make a copy of the repo on your machine or github before doing this as you could mess up pretty bad.
Get the latest master, revert your local version to the commit you want to be on the master (latest 2018) (find the commit and right click revert to this revision) and push that.
You have a nice answer just about what you are trying to do in an easier way here :D
The problem that i am facing is that when i merge my branch with the development branch to update my branch it deletes a big part of my work.
The strange thing is that when i try to solve it with Visual Studio to merge it doesn't not show any merge conflicts.
My branch is fairly up to date but the only diffrence is that the Entity frame work of our database is updated and the Entity frame work of your SQLite database is updated.
The are also placed in seprate projects should that should not effect my work.
The previous merge from dev did have some conflicts but all of them i had solved and my app work fine.
I got my work back with a Restoring a Revision in a New Local Branch but the problem still stay there that i have to merge my branch with dev to test the functions.
I couldn't find any solutions to the problem online.
File structure
Instead of merging dev to your branch, try instead to rebase your branch on top of dev (if you can afford to force push it, meaning if you are not several collaborator working on that same branch)
git checkout myBranch
git rebase dev
The rebase method that VonC suggest did not solve the problem.
But by creating a new branch with information of the older feature branch we could solve the problem by letting some other developer merge the dev branch to the new feature branch.
But i still don't know what the real cause is of the problem.
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
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