Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Best Option</strong></p> <p>Probably the cleanest, least confusing, and safest way to push into your non-bare remote repository, is to push to dedicated branches in the remote that represent your laptop branches.</p> <p>Let's look at the simplest case, and assume you have just one branch in each repo: master. When you push to the remote repo from your laptop, instead of pushing master -> master, push master -> laptop-master (or a similar name). This way the push doesn't affect the currently checked-out master branch in the remote repo. To do this from the laptop, the command is pretty simple:</p> <pre><code>git push origin master:laptop-master </code></pre> <p>This means that the local master branch will be pushed to the branch named "laptop-master" in the remote repository. In your remote repo, you'll have a new branch named "laptop-master" that you can then merge into your remote master when you are ready.</p> <p><strong>Alternate Option</strong></p> <p>It's also possible to just push master -> master, but pushing to the currently checked-out branch of a non-bare repo is generally not recommended, because it can be confusing if you don't understand what is going on. This is because pushing to a checked-out branch doesn't update the work tree, so checking <code>git status</code> in the checked-out branch that was pushed into will show exactly the opposite differences as what was most recently pushed. It would get especially confusing if the work tree was dirty before the push was done, which is a big reason why this is not recommended.</p> <p>If you want to try just pushing master -> master, then the command is just:</p> <pre><code>git push origin </code></pre> <p>But when you go back to the remote repo, you'll most likely want to do a <code>git reset --hard HEAD</code> to get the work tree in sync with the content that was pushed. <em>This can be dangerous</em>, because if there are any <em>uncommitted</em> changes in the remote work tree that you wanted to keep it will wipe them out. Be sure you know what the consequences of this are before you try it, or at least make a backup first!</p> <p><strong>EDIT</strong> Since Git 2.3, you can use "push-to-deploy" git push: <a href="https://github.com/blog/1957-git-2-3-has-been-released">https://github.com/blog/1957-git-2-3-has-been-released</a>. But pushing to a separate branch and then merging is usually better since it does an actual merge (hence works with uncommitted changes just like merge does).</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload