Databases
StackOverflow2013
Postsdbo
POIs squashing commits into one best practice (for this particular workflow)?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POIs squashing commits into one best practice (for this particular workflow)?
    primarykey
    data
    text
    <p>I have the following <code>git</code> workflow:</p> <ol> <li>Create new feature branch</li> <li>Work on feature branch</li> <li>Commit often</li> <li>Once feature is complete, merge into <code>master</code> branch</li> <li>Rinse and repeat</li> </ol> <p>However, sometimes, I have the need to revert a whole feature from master. This could involve a whole lot of <code>revert</code>ing. (<em>The reason for needing to revert a feature is I have a website that works off of one repo. From there, we use a script that deploys the site to either our Production site or Staging site. Both are done from our master branch. Don't ask, that's just what I've been given to work with. Sometimes, I'm working on something that I stage, but then an immediate change needs to be made, so I needed some way to pull my changes in order to clean the repo.</em>)</p> <p>I'm thinking that the easiest way to do so is if each feature branch has only one commit. Then I could <code>revert</code> that commit. So naturally, I am thinking of squashing all commits of a feature branch into one, prior to merging it into <code>master</code>.</p> <p>So now my workflow would look like:</p> <ol> <li>Create new feature branch</li> <li>Work on feature branch</li> <li>Commit often</li> <li>Once feature is complete <strong>git rebase -i HEAD~number_of_commits</strong> (or if remote branch is available, <strong>origin/feature_branch</strong>)</li> </ol> <p>Is there any issues with this logic? Does it go against any best practices? I did some testing myself and the whole workflow seems to run smoothly and solves my problem, but I wanted to run the idea by other (smarter) Git-ers to see if there is anything wrong with it.</p> <p>Thanks!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USFillip Peyton
    1. USFillip Peyton
    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. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. USmontooner
      1. VTFavorite
    1. COHave you looked into `git merge --squash` ? Any particular reason why you chose `rebase` instead of using the `squash merge` ? You would not have a linear history when you do a `merge`, but the commits in the feature branch would still have linear history, and you would just have one merge.
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. USTuxdude
    2. COI just looked into that for my scenario. Very nice. I don't know which I would use more (maybe `rebase` since I throw away these branches somewhat often), but having the history on my feature branch is a nice thing to have. Thanks for your help!
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. USFillip Peyton
    3. CO@Tuxdude: Consider making that an answer. It probably *is* the answer.
      singulars
      1. POIs squashing commits into one best practice (for this particular workflow)?
      1. USsleske
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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