Changes between Version 48 and Version 49 of WorkingWithGit
- Timestamp:
- Aug 26, 2016, 6:30:17 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WorkingWithGit
v48 v49 95 95 Because of Git's distributed nature, a commit on your local machine is not immediately available on the central server, like it was the case with Subversion. This means that you can continue to prepare further changes in additional commits before you publish your changes as a set. In fact, it is a very common practice in Git to do many small changes that are logically consistent in themselves and then publish them in one step. 96 96 97 If you have commit access, you can publish your commits using `git push <remote-name> <branch-name>`. `<remote-name>` is the name of the repository to which you want to push. The most common push target is the location you initially cloned, which is automatically named `origin`. `<branch-name>` is the name of the branch you want to push. The Git equivalent to Subversion's `trunk` is called `master`. It is considered best practice to always specify your push target and the branch you are pushing, since git's default is pushing all branches that have a remote equivalent when you run `git push`, which might publish changes that you do not consider final yet (you can disable this behavior by changing the `push.default` git config setting to `nothing`, see `man 1 git-config`).97 If you have commit access, you can publish your commits using `git push <remote-name> <branch-name>`. `<remote-name>` is the name of the repository to which you want to push. The most common push target is the location you initially cloned, which is automatically named `origin`. `<branch-name>` is the name of the branch you want to push. The Git equivalent to Subversion's `trunk` is called `master`. It is considered best practice to always specify your push target and the branch you are pushing, since git's default is pushing all branches that have a remote equivalent when you run `git push`, which might publish changes that you do not consider final yet (you can disable this behavior by changing the `push.default` git-config setting to `nothing`, see [https://git-scm.com/docs/git-config git-config(1)]). 98 98 {{{ 99 99 git push origin master … … 118 118 Finally, push the new commit using 119 119 {{{ 120 git push [origin <branchname>] 121 }}} 122 123 '''T.B.D.:''' Here as well see config setting for {{{push.default}}} [#Initialsetup above] requiring a target branch, i.e. it should now be e.g. {{{git push origin master}}}. 120 git push origin <branchname> 121 }}} 124 122 125 123 == Common `git` tasks & notes about MacPorts' Subversion export == … … 156 154 Note that L1 and L2 have been modified by this operation; their commit IDs changed because of that. This new state can be pushed back to origin without the need for a merge commit, and the history graph will stay linear. '''We recommend that all developers rebase their changes rather than merge when conflicts occur during pushing.''' 157 155 158 '''T.B.D.:''' See config setting for {{{branch.autosetuprebase}}} [#Initialsetup above].159 160 161 156 ==== Putting the background knowledge into production ==== 162 157 First, get all new commits from the remote repository using `git fetch <remote-name>`, where `<remote-name>` identifies the repository from which you want to fetch and defaults to "origin": … … 178 173 '''Warning:''' `git pull` without the `--rebase` flag is a shorthand for `git fetch && git merge origin/master`, which will automatically create a merge commit if it thinks that's necessary. 179 174 180 If you do not want to remember passing `--rebase` to `git pull` every time you run it, you can set a couple of `git-config(1)`options to make it the default:175 If you do not want to remember passing `--rebase` to `git pull` every time you run it, you can set a couple of [https://git-scm.com/docs/git-config git-config(1)] options to make it the default: 181 176 182 177 - Setting `pull.rebase` to `true` will change the default to always rebase when calling `git pull`. Note that this will also flatten any local merge commits you might have committed on purpose with `git merge`, which might be undesirable when merging development branches for MacPorts base. Consider using the `preserve` setting, which avoids this. … … 195 190 1. Use the body to explain what and why vs. how 196 191 197 If you don't want to remember these rules, you can configure your git client to load a template whenever it prompts you for a commit message by setting the `commit.template` `git-config(1)`option. The KDE developers [https://quickgit.kde.org/?p=macports-kde.git&a=blob&h=14f952f776b9f54263671cc2aba5886c6ebee75b&f=contrib%2Fgit-setup%2F.git-commit-template&o=plain have a nice example].192 If you don't want to remember these rules, you can configure your git client to load a template whenever it prompts you for a commit message by setting the `commit.template` [https://git-scm.com/docs/git-config git-config(1)] option. The KDE developers [https://quickgit.kde.org/?p=macports-kde.git&a=blob&h=14f952f776b9f54263671cc2aba5886c6ebee75b&f=contrib%2Fgit-setup%2F.git-commit-template&o=plain have a nice example]. 198 193 199 194 === Reverting changes === #revert