StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Check out <code>git fetch;git rebase origin/master</code> or <code>git pull --rebase</code>, both honor the order of the commits in the master repository because it rebases, sticking local commits on top. You don't care about the order of the local commits as much on local branches anyway because only you have them. Try it out, but use with care, e.g. duplicate a branch before rebasing until you're used to it.</p> <p>In general, you're talking about git workflow, and I've found that there are two general workflows that you should get familiar with. Be aware that I'm talking from personal experience on how to minimize conflicts:</p> <ul> <li>Rebase-first workflow (for cleanest commit history, pushes the burden of conflicts generally to uncommitted code)</li> <li>Merge workflow (sometimes simpler when there are a lot of changes that would conflict, I usually use this only as a fallback)</li> </ul> <h2>Example Initial workflow</h2> <pre><code>git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that. git branch temp_branch // copy of the master git checkout temp_branch git add changedFiles;git commit changedFiles; // A change from november 2nd. git log // Now your dev branch has a new commit on top of an otherwise old branch. git log origin/master // You get a listing of the commits from the origin repository, the master branch. </code></pre> <p>Generally I use origin/master for development staging, with git tags standing for the commits that are made live releases.</p> <p>Now here's where the problem occurs, and where the choice of workflow comes into play: let's say there's a commit that came from another dev repository up in master, e.g. a commit from october 15th. Maybe it was commited by another developer, maybe by yourself.</p> <p>Your choices: Merge or rebase.</p> <h2>Merge</h2> <p>Introduces an extra commit, honors your local (unpushed) branched dev history over the canonical (origin/master) history, causes a little more potential for conflicts <strong>for others and other branches</strong>. Essentially you're saying "my commit order will be mixed with the master branch commit order" as opposed to reordering commit history.</p> <pre><code>git merge origin/master // merge commit introduced ... // Resolve any conflicts, and finalize the merge commit. git checkout master;git rebase temp_branch // Move the changes to master. git push origin/master // Pushing changes, including merge commit, to origin/master </code></pre> <p>At the end, commit history will look something like: August-October-November-MergeCommit</p> <h2>Rebase</h2> <p>No extra commits, honors commits already in the canonical repository (origin/master) over local commits, conflicts that occur will generally occur on commits that the developer has not yet commited (and thus no-one else can account for).</p> <pre><code>git rebase origin/master // ... // Resolve any conflicts... git rebase --continue or git rebase --abort ... // Resolve any conflicts... git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master. git push // Push all changes to the canonical repository. </code></pre> <p>Note: If you end up having to do more than two conflict resolutions, -then- it is a good time to <code>git rebase --abort</code> and fall back to doing a merge.</p> <hr> <p>Try out the process, see if it makes sense for you! It takes some experimentation before you can really get tactics that work well for your development in git, I guess because there are so many more approaches once you get decentralized.</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