StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>A few notes on how git works (non technical):</strong></p> <p>When you rebase, git takes the commits in question, and "recommits" them on top of a clean history. This is to prevent the history from showing:</p> <pre><code>Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge Commit SHA1: aaaa -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg </code></pre> <p>After a rebase, it may look like this (or similar):</p> <pre><code>Description: tree -> rebase Commit SHA1: aaaa -> hhhh </code></pre> <p>The issue is that the new commit you are attempting to push out there is <strong>NOT a descendant</strong> of the commit on the tip of the branch you are pushing to.</p> <p>Now, you know that the same info is in the commits, but git is being responsible by not just overwriting those commits out there (bbbb-gggg in the example above).</p> <hr> <p><strong>Shared Repo Model</strong></p> <p>If you are using a shared repository, then things like this can get mighty confusing. Let me explain why. Say another developer pulled down the branch, and they have commits <strong>aaaa -> gggg</strong> in their branch. Then they make a commit <strong>iiii</strong></p> <p>In the meanwhile, you rebased and forced a push, causing the tree to look like this:</p> <pre><code>Description: tree -> rebase Commit SHA1: aaaa -> hhhh </code></pre> <p>When the other developer tries to push, he gets a "non-fast forward" message. When he does a merge, then both histories are RELINKED together, and you end up with a <strong>mess</strong></p> <p>Something like this (messy):</p> <pre><code>Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge Commit SHA1: aaaa -> hhhh -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg -> iiii -> jjjj </code></pre> <p>IN other words, if others are pulling AND pushing, it's better that you stick with git merge, or <strong>AVOID PUSHING</strong> until after the rebase (and only rebase your work).</p> <hr> <p><strong>Publicly Visible Repository Model</strong></p> <p>Perhaps you are using a different (more gittish) model where you just want people to be able to pull from your repo. In this case, git push --force isn't too bad, because then they can deal with keeping up with it. They can rebase <strong>their changes</strong> to be on top of your changes before giving their patches to you. It prevents your repo from getting all messed up.</p> <p>However, there may be a better way for you. <strong>git push --mirror</strong></p> <p><a href="http://www.kernel.org/pub/software/scm/git/docs/git-push.html" rel="noreferrer">From http://www.kernel.org/pub/software/scm/git/docs/git-push.html</a></p> <blockquote> <p>Instead of naming each ref to push, specifies that all refs under $GIT_DIR/refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote..mirror is set.</p> </blockquote> <hr> <p>One of the great things about <strong>git</strong> is that it is very flexible and allows for many different kind of workflows. But it's real strength lies in the fact that it is a distributed model, so I believe that the most ROI can be reaped by using it that way.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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