Changes between Version 48 and Version 49 of WorkingWithGit


Ignore:
Timestamp:
Aug 26, 2016, 6:30:17 PM (8 years ago)
Author:
neverpanic (Clemens Lang)
Comment:

Link to manpage on git-config(1), clean up remaining branch.autoSetupRebase references

Legend:

Unmodified
Added
Removed
Modified

  • WorkingWithGit

    v48 v49  
    9595Because 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.
    9696
    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`).
     97If 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)]).
    9898{{{
    9999git push origin master
    … …  
    118118Finally, push the new commit using
    119119{{{
    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}}}.
     120git push origin <branchname>
     121}}}
    124122
    125123== Common `git` tasks & notes about MacPorts' Subversion export ==
    … …  
    156154Note 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.'''
    157155
    158 '''T.B.D.:''' See config setting for {{{branch.autosetuprebase}}} [#Initialsetup above].
    159 
    160 
    161156==== Putting the background knowledge into production ====
    162157First, 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":
    … …  
    178173'''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.
    179174
    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:
     175If 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:
    181176
    182177 - 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.
    … …  
    195190 1. Use the body to explain what and why vs. how
    196191
    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].
     192If 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].
    198193
    199194=== Reverting changes === #revert