Understanding the Git Workflow • Hacker News Board

Re: Understanding the Git Workflow

#31

Post by joelhaasnoot » Sun, Jul 31, 2011, 5:44 PM UTC

Hmm, this makes sense to me: lots of Git features I'd forgotten or not used before.

Can anyone sketch my "merging" strategy I should be using in my scenario: - Have 3 branches dev, stage and master - Bugs are fixed on master, bigger bugs/changes on stage and new features on dev - Big functionality changes/additions come in the form of new branches, which currently I first merge with dev, then with stage and if everything is OK, with master. This doesn't always work well due to the timing of things: sometimes my dev branch is out of date with the master and needs fixes from the master before applying.

How should I handle merging the branches?

Re: Understanding the Git Workflow

#32

Post by cvandyck76 » Sun, Jul 31, 2011, 5:53 PM UTC

joelhaasnoot wrote: post #31

Hmm, this makes sense to me: lots of Git features I'd forgotten or not used before. Can anyone sketch my "merging" strategy I should be using in my scenario: - Have 3 branches dev, stage and master - Bugs are fixed on master, bigger bugs/changes on stage and new features on dev - Big functionality changes/additions come in the form of new branches, which currently I first merge with dev, then with stage and if everyt…

I wouldn't have two separate branches for bugfixes and then one for new features - as you noted, it can get hairy. Personally I find the git-flow model very straightforward.

Do normal feature development and bug fixes on the develop branch; save master for production releases. When it's time to make a release, cut a release branch (e.g. r/1.0.1) from the develop branch. Bug fixes that are made on that branch should also be merged into develop. Once the release is made, merge r/1.0.1 back into master and develop and continue on as normal.

Also see: https://github.com/nvie/gitflow

Re: Understanding the Git Workflow

#33

Post by endlessvoid94 » Sun, Jul 31, 2011, 6:10 PM UTC

After reading this, I finally motivated myself to read through the man pages for git pull, fetch, merge, and rebase.

Thanks :-)

Re: Understanding the Git Workflow

#34

Post by joelhaasnoot » Sun, Jul 31, 2011, 6:20 PM UTC

cvandyck76 wrote: post #32

joelhaasnoot wrote: post #31

Hmm, this makes sense to me: lots of Git features I'd forgotten or not used before. Can anyone sketch my "merging" strategy I should be using in my scenario: - Have 3 branches dev, stage and master - Bugs are fixed on master, bigger bugs/changes on stage and new features on dev - Big functionality changes/additions come in the form of new branches, which currently I first merge with dev, then with stage and if everyt…

I wouldn't have two separate branches for bugfixes and then one for new features - as you noted, it can get hairy. Personally I find the git-flow model very straightforward. Do normal feature development and bug fixes on the develop branch; save master for production releases. When it's time to make a release, cut a release branch (e.g. r/1.0.1) from the develop branch. Bug fixes that are made on that branch should a…

The problem is that between a feature being ready and it going into production there is a certain amount of QA/tweaking that goes on. Before I was running into issues where I couldn't fix a much smaller bug than the new functionality due to not having a branch for that. The flow handles that with hotfixes, which I guess works well.

I do think the numbering is excessive however: web software releases so often on a one man team it's mostly extra work.

Re: Understanding the Git Workflow

#35

Post by planckscnst » Sun, Jul 31, 2011, 6:24 PM UTC

eropple wrote: post #25

pilif wrote: post #18

Earlier quoted context omitted.

Commits don't cost money, but time wasted on "added forgotten files"-commits while parsing the history to trace a bug does cost money, so I'd rather not have the commits. Additionally, it's impossible for you or anybody else to find out whether I have rebased my personal history before pushing. As such, it's totally inconsequential for the main repository whether I rebased or not. As I said: I think rebase is a perso…

I dunno, I think the claim that those commits "waste time" (in the sense of any meaningful amount of time, even cumulatively) is a little hyperbolic. I guess you view history differently than I do: I consider all development history to be "public history" regardless of whether it was pulled in from a clone or not. If you commit it to a repository I am going to be fulfilling a pull request from, I want the history the…

So, let's get down to business here, then. What specifically is better about this:

    commit 123facdf Add asynchThingerBopper() to Thinger class.
    commit 9f9babd8 Forgot to add Thinger.h file to 1123facdf

compared with this:

    commit 123facdf Add asynchThingerBopper() to Thinger class.

What specific value does the first scenario add that the second does not?

Re: Understanding the Git Workflow

#36

Post by pflanze » Sun, Jul 31, 2011, 6:33 PM UTC

I've always been an extensive user of rebase -i. Committing partial work often using git commit -a is easier, or at least takes less concentration, than always being careful to commit selectively with git add -p, git commit $files, but it needs squashing of those partial commits later on. I found that git rebase -i wouldn't scale to several days worth of work: I would frequently make errors when dealing with conflicts, and restarting rebase -i from scratch would mean redoing much of the work.

Because of this, I wrote a tool[1] that lets me do the same thing as git rebase -i, but allows me to edit the history changes incrementally, by keeping the history edit file and conflict resolutions around between runs; it does this by creating git patch files from all commits in question. I now always use this whenever I need to do more than one or two changes on some history; also, I'm now often creating commits to just store a note about a thought/idea/issue (the tool automatically adds a tag to the original history head, so I can look at those later on).

I originally wrote this just for me, which is the reason its own history isn't particularly clean and that I'm relying on a set of never-released libraries of mine; also maybe there are other, perhaps more well-known or polished tools than this, I don't know. I guess I should announce this on the Git mailing list to get feedback by the core devs.

[1] https://github.com/pflanze/cj-git-patchtool

/plug

Re: Understanding the Git Workflow

#37

Post by ulisesroche » Sun, Jul 31, 2011, 6:58 PM UTC

diminish wrote: post #7

pilif wrote: post #3

The minute I learned about "rebase -i" and "add -p" has changed how I think about commits. I learned how I could easily keep the history clean and conversely, I learned the huge value that a clean history has for maintenance. Now, building the commits as self-contained entities that don't break the build in between not only helps me while searching bugs later on, it sometimes helps me detect code smells around unneed…

just like you, i enjoy rebase -i, to change history; but I also hear some poeple claim the history should be kept as it is and should not be rewritten. What are your arguments for rebase?

For better integration with an issue tracker, and because a master branch should have a formal commit history.

I make tons of little commits on a local branch with messages such as "reformat styles", "whoops, fixed typos", "fixed the query", and such. I use "rebase -i" to squash all of them together with a better, and more formal, commit message, like "Repairs and styles main navigation, closes #9".

I hate a master branch with a commit history with casual commit messages.

Re: Understanding the Git Workflow

#38

Post by sandofsky » Sun, Jul 31, 2011, 8:32 PM UTC

decklin wrote: post #28

The idea that fast-forward merges are easier to follow is subjective. I find my --no-ff history easier to read. This author doesn't. What always using fast-forward merges really means is that you rebase each branch onto master once it's ready to be public. Therefore, instead of resolving conflicts when the branch is merged, the commits are rewritten to avoid introducing the conflict in the first place. Sometimes, thi…

In my experience, on large distributed projects the person integrating changes into master is rarely the same person who authored the change.

For example, when Linux branches are pulled upstream, if your code creates a conflict your branch will just be rejected and you'll be told to fix.

Rebase forces the author to solve more of these problems before submitting their change for integration.

I don't think rebase is an end-all solution for the reasons you've described. It's perfect for medium sized changes you can easily verify afterwards. My day-to-day work usually falls into this category.

In the case of larger sets of all-or-none changes, such as a site redesign, it makes perfect sense to maintain a parallel line of development. Cleanup probably isn't worth it, and the separate branch serves as documentation. You should consciously create a new public branch.

In this case, I can understand wanting a "no-ff" merge for documentation. I think you should first consider tags, but sometimes it makes sense to set a stake in the ground with a placebo commit.

The problem is that if you use "no-ff" all the time on trivial changes, then these branches lose meaning.

This post wasn't supposed to be an embargo on "no-ff." My case is that people default to "no-ff" to pave over deeper issues.

Re: Understanding the Git Workflow

#39

Post by sandofsky » Sun, Jul 31, 2011, 8:41 PM UTC

swah wrote: post #5

He should start the article with the last paragraph.

People could then read the summary and skim through the rest. The summary is there just to help you remember.

If people don't internalize the reasoning, it's a disaster waiting to happen.

Re: Understanding the Git Workflow

#40

Post by js2 » Sun, Jul 31, 2011, 8:55 PM UTC

gruseom wrote: post #24

js2 wrote: post #22

Earlier quoted context omitted.

Here's a trick for you: make sure you have rerere enabled. Merge the end commit, resolve all the conflicts and commit the merge (or just run rerere to record the conflict resolution). Then abort the merge or reset back to undo it. Now do the rebase, which will re-use the resolutions for any identical conflicts. You still have to deal with conflicts unique to the intermediate state, but in my experience rerere helps a…

I tried rerere once and it felt too much like magic to me, i.e. too complicated in a way that I didn't trust. Experience with conflicts has led me to eschew magic merge tools and rely on the simplest strategies: 1. minimize conflicts; 2. bite the bullet and deal with them manually. (Edit: my question about rerere is: how identical is "identical"? How can I be sure that it will redo what I did before in exactly the wa…

There is nothing really magic about rerere. During a merge, it records each conflict. When you commit the merge, it records your resolution of the conflict. If that _identical_ conflict occurs again, it re-applies the same resolution. You can choose whether it marks the the file as resolved or not, which allows you to easily review what was done before committing the merge.