• Atlassian forking-workflow guide

The default push behavior may not be what you expect: if a branch you are not working on changes, you may not be able to push your own branch, because git tries to check them all. To avoid this, use:

git config push.default upstream

to set the default push.default behaviour to push the current branch to its upstream branch. Note the actual string to set depends on the version of git; newer versions allow to use:

git config push.default simple

which is better; see also discussion on this stackoverflow page.

If you want to see which commits would be sent to the remote repository upon a git push command, you can use (e.g. if you want to compare with the origin/develop remote branch):

git log origin/develop..HEAD

to see the logs of the commits, or:

git diff origin/develop..HEAD

to see also the differences among the current HEAD and the version on origin/develop.

You can switch to another branch with:

git checkout newbranchname

and you can see the list of checked-out branches, and the one you are in, with:

git branch

(or git branch -a to see also the list of remote branches).

To tell GIT to always push a local branch (checked-out) to a remote branch called remotebranchname, check out the correct local branch and then do:

git push --set-upstream origin remotebranchname

From now on, you will just need to run git push. This will create a new entry in .git/config similar to:

[branch "localbranchname"]
  remote = origin
  merge = refs/heads/remotebranchname

To rename a branch locally, from oldname to newname:

git checkout oldname
git branch -m oldname newname

If you want also to rename it remotely, you have to create a new branch and then delete the old one. One way to do it, is first editing ~/.git/config so that the branch points to the new remote name, changing refs/heads/oldname to refs/heads/newname in the correct section:

[branch "newname"]
  remote = origin
  merge = refs/heads/newname

Then create the new branch:

git push origin newname

and finally delete the old one:

git push origin :oldname

(notice the : symbol). Note that if you are working e.g. on GitHub, there may be a filter to disallow the deletion of branches (check in the repository settings, and then under "Branch management"). Moreover, the "Main branch" (set in the repository settings, under "Repository details") cannot be deleted.

If you want to create a new tag, e.g. for a new version, and you have checked out the commit that you want to tag, simply run:

git tag TAGNAME

(e.g., git tag v0.2.0). Afterwards, remember to push the tag to the remote repository (otherwise it will remain only local):

git push --tags

This will create a new newbranchname branch starting from tag v0.2.0:

git checkout -b newbranchname v0.2.0

Then, if you want to push the branch remotely and have git remember the association:

git push --set-upstream origin remotebranchname 

(for the meaning of --set-upsteam see the section git_associate_local_remote_branch above).

You can find these settings in the repository settings of the web interface, and then under "Branches".

(this removes one commit only, and you should have no local modifications; if you do it, be sure to avoid losing your modifications!)

Syncing a fork with the official repository currently (Dec 2018) can not be done via the GitHub web interface. You will need to:

• commit all your changes (and if you want, also push them to your fork)
• run git pull upstream develop to merge all "official" changes in your branch

At this stage, three things can happen:

• Changes have happened only on different files. Then they are ported into your branch, you can continue to work happily.
• Changes have also happened to files you edited, but git could merge without problems. It will ask you then to store a message for a commit that represents the merge, you can simply accept the default message.
• There are some conflicts you have to resolve. Then, do a git status, files already 'added' are successfully merged, while files marked as 'both modified' need to be fixed - open them, fix all conflicts (your version and the official version are marked with <<<<<< and >>>>>> signs). When you fix everything, add these files and then commit + push to finish the merge operation.

Note! If, while merging, you notice there are other things to fix, it's good practice to first complete the merge, commit, and then continue to fix (you can push at the end). Otherwise, your fixes will be "hidden" inside the commit representing the merge.

If you want to be able to pull/checkout from pull requests sent on the upstream repository, to test them or rebase on them locally, add the following line to the [remote "upstream"] section of your .git/config file, in the top folder of your repo:

fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

Once you do this, you can merge from a pull request using:

• git fetch upstream followed by
• git merge upstream/pr/8 (replace 8 with the pull request ID you want to merge from)

More information (e.g. on how to continue working on a inactive pull request) here