When I merge my code from Dev branch to Live sometimes accidently we check-in debug =true in Live branch. How can i make sure after check-in it is set to false for Live branch.
Related
I erroneously committed local changes on the "production" branch my organization uses for a project and opened a pull request to merge those changes (one simple commit) into the "development" branch (which is where changes should go in the period of time while they are not consolidated into a release).
Obviously, the "production" branch is hundreds of commits behind the "development" one. Is there a way I can change the pull request to be merging changes from another branch (the appropriate one, branching from "development") or my options are just to pull changes from "development" into my local branch involved in the PR or close the PR and open a new one?
Ever since I had to recreate my dev branch due to some mishaps with Git, Sourcetree doesn't prepopulate the "dev" branch in the pull and push dialogs. Every other branch works fine, but not dev. It's not a big deal, but I have to select dev manually every time. What gives?
Screenshot:
The "Remote branch to pull" dialog is pre-populated based on the remote branch that is being "tracked" by your local branch. (When you check out or push to a remote branch, SourceTree usually sets this up automatically.)
If your dev branch is not tracking a remote branch, then the dialog will load with no selection. To change this, right-click the branch and select 'Track remote 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.
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.
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)