I have a forked a repo on GitHub. I have a master on this fork so that I can branch features separately and do pull requests to the upstream/master per feature. The only time my master changes is when the origin changes, meaning I don't merge my features into my master. I have updated my master from the origin and I now need to merge those changes into one of my feature branches.
The problem I am encountering is that I seem to have about 40 Unstaged files in my master branch. There appears to be 2 to 3 of each file marked: ~Automatic Revision, ~HEAD, or ~HEAD_0.
I am not terribly familiar with Git, though the basic concepts seem to be straight forward. I think most of my issues are me not understanding how sourcetree works.
First, Why would there be Unstaged/Uncommitted changes immediately after checking out my master?
Second, How can I be sure I am merging a complete copy of my master to my feature branch so that I am not unnecessarily altering files that are not part of my feature changes while issuing my pull request from my feature branch back to the upstream/master?
Resolved by deleting and re-cloning master branch.
Related
I am analyzing commits from project apache/mina-sshd but I am running to a problem:
All commits in the branch 0.9.x from project mina-sshd (except for the first 3 commits) belongs to branch master but still be shown in branch 0.9.x. Can anyone explain this for me, please? I am thinking it might be because those commits are merged, maybe?
Is there anyway to check what branch a commit belongs to by Python?
Your branch 0.9.x is derived from master. So at the point the branch gets created, it contains all the commits that the other branch has at that point. If you add additional commits to the master after the branch is created, they will not appear anymore unless you merge them.
So this isn't your typical 'just rebase' issue (Atleast I don't think).
I'd like to know how I can create more than one pull request without effecting past commits. Here is my current scenario:
I forked a repository
I made the change on my local master (so stupid, I know)
I made a PR with the changes
They were accepted but are auto-merged by a bot in a few days
Here's the problem, I'd like to keep contributing but with individual PR's in the meantime that don't list all the old (but yet to be merged) commits I've made. My idea was to get upstream, rebase my master, and work from there (properly this time with branches). However upstream/master conflicts with master so it won't allow me to. I'm afraid to rebase my local master with the current original because I fear it may 'delete' the code for my pull request and somehow invalidate it.
Any idea how I can fix this? Or do I just have to wait for the bot to make the merge from my PR then rebase from master.
My idea was to get upstream, rebase my master
Don't: set a branch on your current local master, where you have your old (but yet to be merged) commit.
git switch -c mywip master
(wip: work in progress)
This uses the new git switch command (Git 2.23+)
Then reset master to upstream master
git fetch upstream
git switch master
git reset --hard upstream/master
Work from there, in a new branch, for a new future PR (based on a code which does not list the old -- but yet to be merged -- commits).
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.
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.
I'm trying to figure out whether I should do my development on my clone of an upstream branch or create a local branch of it first, i.e.
fork upstream
work on my master
issue pull-request against my master
... time passes ...
merge upstream/master into my master
back to 2.
or
fork upstream
branch my master into dev
work on dev
issue pull-request against dev
... time passes ...
merge upstream/master into my master
rebranch master or merge master into dev
back to 2
The reason i consider the second workflow is for scenarios where my pull request isn't accepted or only partially accepted and once i merge upstream i want to make sure that my local is identical to upstream so i don't base future work on a divergent mutation of upstream. Or is there a command when i pull from upstream to master to make my local master identical to it (i.e. discard all local changes?)
When dealing with an upstream repo, I usually do what I think your second workflow suggests. To wit:
I create a branch from upstream's master. If I'm working on a specific feature or bug, I'll name the branch to reflect that; otherwise, I'll call it dev or whatnot.
Work on dev, rebasing from upstream's master as necessary.
Push dev (or whatever I called the branch) and issue my pull request.
Continue pulling upstream's changes down into my master branch.
I.e., I don't do any work on master. This creates a simple, clean branch/pull request for the upstream maintainer.
There's also the very important git rebase that pulls/merges any external changes to the branch you rebase to. That's the way I committed changes to Qt in the past (which is hosted on gitorious which has the great merge request feature). Steps 1 and 2 will probably just be number two for you.
create own clone of "master" on a seperate project
work on the branch currently developed or create a new work branch.
before making the pull request, do a git rebase origin/masteror something similar to make sure your commit applies cleanly to the current master. This has the nice side effect that your changes appear "on top of the stack", ie after all other commits.
Hope this helps you in what you're trying to do.