My company uses github. When I want to do a pull request I need to make my PR from my fork to the main repo into the staging branch. By default my PRs point to the master branch, so for every pull request I have to change which branch I'm merging into. I know that you can set the default branch in github. I want the default branch to remain master, but I want my pull requests to point to staging by default. Is that possible?
In the image below I don't want to have to change base: master to base: staging every time. The bigger pain is when I forget to change it to staging.
Go to settings page, branches, ... and select the default branch.
Related
I have a pull request that is currently against the master branch and I want to change its base to a branch that is two commits behind master.
When I change the base branch in GitHub Enterprise the two commits that are not on master also get dragged into the pull request.
Is there a way to change the base branch but just have the commits that are actually in the pull request? I don't see any options other than the branch name, and my commit and one of the other commits touches the same file but not the same lines.
When people click on Cataclysm-DDA on my profile (https://github.com/DanielPBak?tab=repositories), they are directed to my master branch, but I'd rather they be directed to a different branch (washboard_batch) where I've actually done some work.
I'd like to do this without changing the default branch. The only thing I want to change is the branch that a visitor is initially directed towards.
How can I do this?
Your default branch is named master. If you have admin rights over a
repository on GitHub, you can change the default branch on the
repository.
https://help.github.com/articles/setting-the-default-branch/
In my git repository I have three branches: master: default, dev: compare, and temp.
When I create a Pull Request from temp branch it defaults to dev as the target.
It is in contradiction with what Microsoft documentation says:
Change the default branch used to merge code into when your team
creates new pull requests. This is useful when you want to use a
branch other than master for the main line of development in your
repo.
Am I missing something?
For default branch, it helps you to treat the branch as default when cloning the git repo locally or creating a PR.
Such as if you treat master branch as default branch (by default), when you cloned the git repo locally, the local branch is master. And when you creating a PR, it will automatically treat master branch as the target branch.
For compare branch, it helps you to decide how many commits on the other branches are behind or ahead by comparing commits on other branches with the compare branch.
Such as for above example, develop branch is compare branch, and master branch and nn1 branch are compare with develop branch.
For comparing master branch with develop branch, there has 0 commits behind and 0 commit ahead (master branch same as develop branch). For comparing nn1 branch with develop branch, there are 3 commits behind and 48 commits ahead.
I did some quick tests in my VSTS tenant. It looks like the default branch of a new pull request is always the Compare branch, rather than the Default branch. So if you set your master branch as Compare branch, it should become to the default for new pull requests.
Not sure if it is bug of VSTS, or if they change the behavior of pull request without updating the doc.
Update:
I did some further research. It turned out that this change was introduced in a Oct 2016 feature roll out:
You can now set your compare branch to something other than the
default branch. This setting will be remembered on a per-user basis.
Pull requests and new branches created from the Branches page will be
based off the branch you set as the compare branch.
So the doc needs to be updated.
I am using github and I have the following question, I have a master branch and I created a new branch out of master by doing
Git branch {branchname"
Git checkout {branchname}.
Now I need to edit some settings file , should I edit this file from my new branch or the Master? If I edit it from the new branch, then each time I create a new branch for different projects, then I should be modifying this settings file…but at the same time if I edit it by being on master branch, then when I merge/update master branch later, then I would loose the changes. Can someone please clarify the best way to handle this? If I have to do it from Master, then how I can stash it as I never push anything from master branch.
it depends what you want. If you want the new settings to be available everywhere, you need to modify the file in master, check it in, then rebase any existing branches to get the settings.
If you only want the changes in the other branch, make them there. If you ever merge the other branch back into master, then master will then have them.
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.