9 ms·
Simple git workflow is simple
- aparadja 13y agoI understand that collaborating on code is a hard problem. But if this is the simplest solution, part of me wants to throw it all in the trash and start over. It's just not good enough.
- girvo 13y agoI read a funny quote somewhere, it basically said that git is a great library for building a DVCS... Basicailly, I agree with you. What I'd personally like to see more of is an easy way for a company to define a workflow for version control, using git as the underlying mechanism, that fits exactly how they want it to work (think, if the company wants Git Flow, or some other workflow, they define it in my imaginary tool), but for the most part the developers never have to drop down to git to use it. They have an abstraction layer over the top of it. I saw a paper, gitless, I think it was, that is trying to do something similar but less ambitious. Perhaps in the future we'll see stuff like it. GitHub Desktop and Atlassian Stash also do something similar, but not quite what I'm getting at.
- RaphiePS 13y agoThis is a fantastic idea. Even the "nice" git tools like Github's desktop app don't abstract over tracked files and branches and all the confusing git plumbing. It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature." I believe that version control should really get out of your way, and right now, that definitely isn't the case. To me, all the arguments about git's power just sound like "why use Dropbox when you can just sync your files with FTP?"
- hdevalence 13y ago> It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature." Maybe, but it might instead be better to ask people to invest a small amount of time in learning to use tools that make them more effective at doing their job. "I'm working on a new feature" and "I'm done with the new feature" are, sadly, not actually expressive enough concepts to deal with the problem. Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox". Git solves problems significantly more complicated than "I'm working on a new feature / I'm done working on a new feature". EDIT: when I say "conceptual level", I mean, "what you do with it", not "how easy it is to use". Obviously, Dropbox is more usable than FTP. My claim is that Git provides a much different level of power than "I'm working on a feature/I'm done with a feature", which is not a sufficiently expressive concept to deal with software development.
- RaphiePS 13y ago> Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox". I disagree. My mom loves Dropbox -- she just sticks a file in a folder like she always does and it's magically synced. If she were to use FTP, she'd have to set up a server, remember login credentials or find her public key, and grab an FTP client. And not every client supports automatic syncing either, so she might have to manually trigger a sync. Of course, FTP has way more power and flexibility than Dropbox, just like git vs <proposed VCS>. If your workflow is especially complicated, I'm sure all the git functionality comes in handy and an abstraction would be a hindrance. But most workflows, I'd argue, don't need all the plumbing.
- crazygringo 13y agoIf you use something like SourceTree, it has buttons for exactly those things, after you hit the 'Git Flow' button in the toolbar. So as long as you want to use the Git Flow model, which is probably the most widely understood/used, you wish has already been granted!
- girvo 13y agoThat's the app was trying think of! Cheers :) what I want to see, is a way of building those work flows in sourcetree, and pushing that out to developers. Would be awesome... And I think I might try and hack on it perhaps.
- Touche 13y agoWhich part do you dislike? I think the basic idea of (1) Create a new branch (2) Develop your feature and commit (3) merge your changes back to master, those steps are as simple as it can possibly be. So is it that this article recommends rebasing (something you don't need to do) what makes it seem non-simple? Or is it the commands themselves (git doesn't have a great ui)?
- CJefferson 13y agoFor a start, lines like: "At this point solve any conflicts that come out of the rebase" Hide (in my experience) huge amounts of complication -- this can get very hairy, and it isn't discussed at all how you do it (and it's more complex than any of the rest of the stuff shown here).
- baq 13y agoperhaps because it's not in any way different than "At this point solve any conflicts that come out of the merge"? isn't conflict resolution usually done on a case-by-case basis?
- lmm 13y agoSo if you e.g. want to abandon the conflict-fixing, and do some things on your branch to make merging easier first, you've got to use a special command, and it's different depending on whether you were merging or rebasing (which is still a great improvement over a year or so ago, when you had to do an incantation like git reset --hard HEAD^). Contrast with svn where abandoning a merge is just a "svn revert" like any other.
- ams6110 13y agoAgree 100%. Whenever go beyond the very basic functionality in git I have to think so hard about what I'm doing that I lose flow on my actual development. In most cases I find using git to be more daunting than actually writing code. Maybe I just don't use it enough. Right now I'm in a job where my git workflow is: pull, (do some work), commit, push.
- king_magic 13y agoHow is this in any way better or simpler than Git Flow? IMO Git Flow is conceptually easy to understand and easy to implement. Using it on a pretty decent sized team (40+ developers) and it works great for us - and is easy for newcomers to the project to pick up.
- codereflection 13y agoThis essentially IS git flow. Edit: Never mind, I wasn't remembering git flow correctly.
- mattdawson 13y agoThis is most definitely not git flow. Git flow advocates explicit merges pretty much everywhere with no fast-forwards and definitely no rebasing.
- codereflection 13y agoYou're right, it's not. I need to stop commenting on HN before I've had coffee. :/
- middleclick 13y agoIs there a link where I can read up the type of Git flow that you are talking about?
- LoganCale 13y agohttp://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
- deleted 13y ago[deleted]
- shaggyfrog 13y agoRebasing locally before "publishing" (pushing) changes to the central repo is definitely okay. It should always be done before pushing the branch for the first time, really, because if someone else has modified develop since you started your branch, you want to make sure your changes are still working and won't break the build (on develop).
- codereflection 13y agoThis is exactly the workflow I have been using for a couple of years now. I'm not sure that labeling it "simple" is accurate, but it is generally easier to understand than some other workflows I've seen.
- lmm 13y agoRebase is a bad habit to get into (because it means other people can't pull your branches), and a pain to fix when it conflicts. Merge master into your working branch instead.
- stinos 13y agoThat's an unfortunate generalization. You can rebase all you want as long as you didn't make your private branch public. (and even then some communication with the other people makes it pullable: tell them to first git reset --hard xxxxx) We use this more othen then not here, and never have problems. It's a great way to work on a dedicated feature while still getting features from others, yet doesn't suffer from sometimes hard to read history. Does this mean rebase is king and merge isn't? No. Is it the other way around then? Also no. Both are fine if you know how to use them.
- lmm 13y ago> You can rebase all you want as long as you didn't make your private branch public. True, but the big benefit of git comes from those branches being public, IMO. > and even then some communication with the other people makes it pullable: tell them to first git reset --hard xxxxx If other people are actually using the changes on your branch (and if not, why did they pull it?), you end up having to do staircase rebases, with everyone fixing the same conflicts again every time they rebase. It's not the end of the world, but it's noticeably worse than using merge. > yet doesn't suffer from sometimes hard to read history IME the only difficulty comes with tools that try and display a linear view of history, and with rebase you sacrifice an accurate time-ordering of commits, making it very hard to find a commit if you were working on several branches at the same time. As long as you configure your tool to show a tree/graph of commits, merged history is easy to follow, and keeps the time-order correct.
- philwelch 13y agoTo me, the big benefit of Git is private branches. When I'm in development I don't need to build clean, atomic commits or have anything worth pulling. I write commit messages like "savepoint 2013-12-12 do not push". I don't want to think about version control because everything is still dirty. I don't know if you've looked at the graph of a Git repo where people merge instead of rebase, but even in that view it's nearly impossible to track even the history of master. It's a mess. Rebase builds such cleaner graphs that I would only advocate merge when you have no reason to ever look at the graph view. For me, almost all of the time, when I'm ready to merge to master I can almost always squash all my work into one or two clean commits. At that point a fastforward is the simplest solution. Merge-only workflows are great for long-lived public branches (if you have an integration and release branch for instance) but they're insane for feature branches.
- jheriko 13y ago> When development is complete record an explicit merge This is so important I felt it necessary to quote it and restate it as a comment. Not knowing this ahead of time caused me to have a serious problem on ship day that most source control solutions make trivial to fix - it got solved in the end, but that hiccup was unwelcome. The result was that I threw git out as a viable option for source control (until hg screws me I have no reason to switch back beyond its popularity). Bad defaults are bugs imo... EDIT: to be clear i'm referring to the advice to use --no-ff for a merge. i am of the opinion that --no-ff should be the default, because using it causes no damage, but not using it can cause problems.
- ionforce 13y agoWhat are you talking about?
- tghw 13y agoI believe he is referring to the git workflows and tutorials that encourage rewriting history in a potentially lossy way. Mercurial can do the same sort of history rewriting, to a point, but it is not the default workflow and requires that you explicitly enable that functionality. Even then, when you push a modified history to the central repository, you have the old history around still. Whether or not this is desired is up to your team's workflow, but it does make it harder to lose something.
- jheriko 13y agonot exactly, i'm referring to the difficulty in undoing a committed merge if you don't use the --no-ff flag as suggested in this article. i believe this is precisely why they suggest using it - because on private branches you can undo merges in much more destructive ways which are not viable on a shared repo - they suggest using --no-ff for when you merge in a feature branch (edit: it is precisely why and there is an article linked from the original discussing the pros/cons of merge and rebase)
- 13y ago
- Pxtl 13y ago"simple" http://tartley.com/?p=1267 http://tartley.com/?p=1267
- deleted 13y ago[deleted]
- thatthatis 13y agoI think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is simpler and more robust.
- scoot 13y agoYes, git-flow is excellent, but like any branch / commit scheme takes dicipline to follow. I often find myself (on personal projects) fiddling with bits on the 'wrong' branch, as I tend to jump ad-hoc from place to place in the code. Probably itself a discipline problem. :-)
- news_to_me 13y agoI have a similar problem; this is what I do: I keep a dev branch to merge to/from whenever I switch focus. For example, when I'm on branch Feat-A, but I want to make a change related to Feat-B (or I already have but haven't committed), I'll stash my changes, merge Feat-A into dev, merge dev into Feat-B, pop my changes off the stash, and commit. The whole switch goes: - "Oops, these changes don't go on this branch" - git stash - git checkout dev - git merge Feat-A - git checkout Feat-B - git merge dev - git stash pop It takes half a minute, but it keeps my branches clean, and lets me move from feature to feature at will. I may add a 'git oops' alias just for this process.
- scoot 13y agoThank you - I've been meaning to think that process through. I'll be doing this from now on if I'm in the same situation rather than 'ah feck it, commit it'!
- easy_rider 13y agoyepyep, this is also how i roll; stashing and popping!
- seanalltogether 13y agoI think these hosting providers are trying to get people into the habit of doing pull requests, which is something base git and git flow doesn't cover. A lot of small teams seem to rely on blind merges with, but as you grow you need better ways to comment/approve/deny changes that random team members might throw into a codebase.
- pyrrhotech 13y agoI really love the design and color scheme of the Atlassian website.
- trumbitta2 13y agoI, for one, like this workflow which is simple and elicits collaboration and creates history: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
- rsanheim 13y agoThis is definitely not simple. So much rebasing. Ugh.
- sergiotapia 13y agoJust use Gitflow peeps. It's simple, not mentally taxing, and having a feature branch for each feature (JIRA ticket, or whatever unit you're using) makes things very atomic and simple.
- sopooneo 13y agoAnd also, if new people join your team, they've probably at least heard of it. There is benefit to being in the middle of the pack.
- deleted 13y ago[deleted]
- ricardobeat 13y agoThis is simple and gives you one branch per feature. Gitflow doesnt offer any guidance on keeping a feature branch up-to-date, assuming either they are very short-lived (frequently untrue) or that you merge from develop polluting your history. In fact you can use this rebasing workflow within gitflow, both are good advice.
- kristoffer 13y ago"In the (somewhat less common) case where other people are also working on the same shared remote feature branch, also rebase changes coming from it" I don't think this use case is uncommon, and unfortunately when you are multiple persons working on a shared remote feature branch you can't rebase the branch from master and then push it either. What work flow do people who have shared remote branches use? Or do you think that way of working is broken?
- reledi 13y agoI use a similar workflow and documented it: http://freeseer.github.io/contribute/basics.html#basic-workflow http://freeseer.github.io/contribute/basics.html#basic-workf... One difference is that instead of fetching and rebasing changes from origin straight into your topic branch, we recommend checking out master, pulling in changes, checking out your topic branch and rebasing against master. This way master is also up to date. As for the .gitconfig tip near the end, I don't think changing the behaviour of such a common command like pull is a good idea. Better to be explicit.
- silasb 13y agoThis is exactly how I do my git stuff. The only thing that I don't like about this is that you need to force your push after you rebash with master as you have noted. Also what solution do you use when you are sharing your feature branch with other people (especially with 1-2 other programmers) while still rebasing off master?
- reledi 13y ago> Also what solution do you use when you are sharing your feature branch with other people (especially with 1-2 other programmers) while still rebasing off master? We don't have that problem because we keep topic branches personal (but still public so they can be reviewed). In other words, our topic branches branch off from master, we don't branch off of someone's topic branch to build a new feature on top of it while the current feature is still ongoing. We try to make branches short-lived and break larger tasks into small parts that can ship individually.
- tmoertel 13y agoThe perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false. Git is a powerful, general tool that lends itself to just about any workflow imaginable and, because of its adaptability, different teams will naturally converge on different Git workflows as "right." These teams, however, have a hard time imagining and thus accounting for the conditions and preferences of other teams, and end up advocating for their workflows as the best workflow. Thus we end up with strongly held and yet contradictory beliefs. Some people claim that "rebasing is a bad habit: it destroys history" while others claim that "rebasing is a good habit: it prevents repo cruft." Who is right? It depends on your preferences, which ought to reflect your team, your project, and your company culture. For my projects, I prefer to edit my work into tight, clean commits before merging them into the mainline branch. That's because I value the logical story of my software's evolution and not the physical story. I want my commits to tell the story that Feature X was built from three sequentially self-supporting changes XA, XB, and XC, not that, while developing Feature X, (1) I was sick for two days, (2) Bob committed an important unrelated hotfix to the mainline tree that (3) I had to work around, and (4) Sally had to later revert Bob's commit. That I was sick, that Bob commited a hotfix, that I had to work around it, and that Sally rolled it back are all real. They happened. But none of those things are fundamental to the nature of Feature X and how I rendered that nature into code. I consider that stuff noise and make sure it's gone before my commits land in production. But that's me. Maybe you care about that stuff. If so, your Git workflow and mine are going to be very different. And that's okay.
- badman_ting 13y ago> The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false. Nothing in the post explicitly says this, nor is it implied. You just took 7 grafs to say "the best tool for the job".
- tmoertel 13y agoThanks for your comment. To clarify, my comment was about "discussions of Git workflows." For example, the very discussion occurring here on HN in the wake of the original post. In this discussion, you will find numerous comments predicated on the implicit belief that there is some global ordering on Git workflows and, therefore, that one workflow can be strictly better than others. Some examples from the top level: > I think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is simpler and more robust. [1] > Just use Gitflow peeps. It's simple, not mentally taxing, and having a feature branch for each feature (JIRA ticket, or whatever unit you're using) makes things very atomic and simple. [2] > How is this in any way better or simpler than Git Flow? [3] > Rebase is a bad habit to get into (because it means other people can't pull your branches), and a pain to fix when it conflicts. Merge master into your working branch instead. [4] Also, I didn't write 7 grafs to say "the best tool for the job." I wrote 7 grafs to say that there is no "the job." Rather, there are many different jobs. Your job might be to record the physical story. Mine might be to record the logical story. Different jobs. Links: [1] https://news.ycombinator.com/item?id=7037265 https://news.ycombinator.com/item?id=7037265 [2] https://news.ycombinator.com/item?id=7037362 https://news.ycombinator.com/item?id=7037362 [3] https://news.ycombinator.com/item?id=7036934 https://news.ycombinator.com/item?id=7036934 [4] https://news.ycombinator.com/item?id=7037057 https://news.ycombinator.com/item?id=7037057
- crazygringo 13y ago> 4. To keep your feature branch fresh and up to date with the latest changes in master, use rebase Could somebody please explain this more? My understanding of rebase which comes from [1] is that it's used to bring a feature branch onto a master branch, or similar, and 'erase evidence' of there ever having been a branch, and squash the intermediate commits on that branch, to make things cleaner. For bringing changes on the master branch into your feature branch, what's the benefit of using rebase instead of just normally merging the changes in? I'm clearly missing something here. They say 'Resolving conflicts during the rebase allows you to have always clean merges at the end of the feature development.', but I don't see what merge vs rebase has to do with resolving conflicts -- you have to resolve conflicts when you merge master into your feature branch just the same. I can understand using rebasing to keep the master branch's history 'clean', but what's the reason with a feature branch? [1] http://git-scm.com/book/en/Git-Branching-Rebasing http://git-scm.com/book/en/Git-Branching-Rebasing
- prezjordan 13y agoRebasing will first undo your changes, get the latest changes from the target branch, then slap all of your changes at the HEAD. It makes things a lot cleaner and easier to revert (without digging through the reflog), whereas merging will intertwine your changes with the master branch. I use it to keep things organized, and also (as you mentioned) for squashing consecutive commits.
- hdevalence 13y agoIn this case, we want to have a logical history that says: this branch has these features A, B, C, D, and rebasing means that we can have the feature branch just have these commits, instead of "A, and then merge in some changes someone else happened to do, then B, C, then some other merges, then D."
- deleted 13y ago[deleted]
- ricardobeat 13y agoTLDR: avoid millions of Merge branch master into xxx commits on a busy project, keeping commit history clean, and allow reverting merged branches easily.
- trustfundbaby 13y agoIn the (somewhat less common) case where other people are also working on the same shared remote feature branch, also rebase changes coming from it: git rebase origin/PRJ-123-awesome-feature At this point solve any conflicts that come out of the rebase. ---------------------- I don't know about this, we've used this before and what winds up happening is a lot of git push --force since the the remote feature branch's history is always being rewritten and won't match the local histories. We only rebase if the feature branch is being worked on by a single developer. And a bunch of other grief ... or am I missing something?
- tomlu 13y agoYes. You can only really rebase onto one remote branch. If two people are working on feature branch PRJ-123-awesome-feature, then you both rebase onto origin/PRJ-123-awesome-feature. You have to merge with master if you wish to keep in sync. Prior to one of you pushing to master you can opt to do a final rebase onto master, but I've always kept these long-running branches in history. I too try to avoid cluttering history with too many merge commits, but it's a very different thing if these long-running feature branches wind up as merges in history.
- scelerat 13y agoOne reason I like git-flow is its insistence on two main branches, master and deploy. In a CI environment, it's great to have a CI pointing at develop so that "finished" features and merges are constantly being tested, plus, you always have a master branch which (theoretically) is only getting fed from fully-tested release branches. Master stays pristine. Develop should also be pristine but if it fails, it's no big deal. Nevertheless, IME finding the right branching/release paradigm in group development situations has not been the biggest problem. The bigger hurdle has been reaching basic understanding of git and SCM tools in general -- even among groups of very good/experienced programmers.
- badman_ting 13y agoIf it works for you then great, but it's kind of crazy to me that anyone would call this "simple". That strikes me as disingenuous, to say the least.
- thyrsus 13y agoMy biggest workflow problem is remembering to commit. Then it occurs to me to commit, I do a "git status" and holy crud, what do all those changes do? So I'm resolving now to commit... when? Any time a new test succeeds (without breaking old tests) -or- Any time I run a test -or- Something else I haven't thought of? It needs to be something more concrete than "when you've done something significant". The mental energy drain of deciding "significant" is a killer. Help?
- malyk 13y agoI think the growing consensus on using a dvcs is that you should work on easily separated chunks of functionality in their own branch. Commit whenever you feel like it throughout the lifecycle of working on that feature, then go back and squash all those random commits into a few easy to understand chunks, and then merge that back into master. For example, I'm working on a simple landing page and form. Some logical points for doing a commit may be something like: 1 basic responsive layout complete for mobile 2 progress on desktop responsive layout (going home) 3 completed desktop responsive layout 4 wired up forms 5 added validation to forms 6 cleaned up duplicate css 7 adjusted css for other, crappy, browsers 8 bug fixes 9 fixed a typo 10 bug fixes & final layout issues Now I'm done and I want to merge that to master. But what I want the commit history to look like is a group of logical steps, excluding things that will be meaningless/useless to other people when they look back at the project history. So I would squash 2 and 3, 4 and 5, and probably 6 thru 10 so that I ended up with 4 total commits 1, 2/3, 4/5, 6/7/8/9/10 that get put onto master. So, you definitely want to try to remember to commit over the course of a feature, but the actual times you commit are a little bit less important because you should clean up your history before you move it to master. In general I try to commit discrete pieces of functionality (like a working form, or a working layout, or a tested class/method).
- yxhuvud 13y agoAs often as possible. Then rebase it to a consistent history with consecutive small changes later when it works. The reason many commits are good to have is that it tends to be easier to extract small independent changes that way.
- jordanlev 13y ago> 6. Perform a final rebase cleanup after the pull request has been approved I understood everything except this step. Could someone clarify this for me? Especially this part: "In some cases ... you can rebase also during development, but I strongly advise against it." Isn't the entire article about rebasing during development? Why did this become a "in some cases" thing now in step 6, when step 4 (rebasing during development) seems like the critical step in the whole process? Otherwise, this is a great step-by-step (especially seeing the commands that get run for each step -- up until now I only understood the rebase process conceptually, but was always scared to try it due to not knowing the exact commands to run in the exact order, or which branch to run them on). Thanks!
- crazygringo 13y ago[Edit: removed confusing paragraph.] "Rebase also during development", I'm assuming they actually mean "squash" commits, since step 4 was all about rebasing. But if the whole point of rebasing instead of merging is to keep the feature branch clean as you go along, why wouldn't squashing "less tidy" commits also be strongly encouraged? Man, you think you know git well enough, you've got git-flow down, then you read an article like this, and realize there are people who use it in a totally different way, and you're confused all over again.
- saosebastiao 13y agoI think he is talking about a cleanup rebase, where you squash all the commits you made where you fixed a typo in your docstrings or fixed your lowerCamelCased acronym keyword.
- michaelmior 13y agoThat's how I interpreted it too. Although personally I think all that should be done in the development stage. I prefer to only approve pull requests once they're ready to be merged. It helps avoid the possibility that some of your "cleanup" accidentally introduced changes in behaviour. Also, a clean pull request is easier to review.
- steveklabnik 13y agogit actually does come with a manpage on workflows: https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html https://www.kernel.org/pub/software/scm/git/docs/gitworkflow...
- deleted 13y ago[deleted]
- VladRussian2 13y agothis post could have been titled "git workflow replicating workflow in centralized VCS (like CVS, Perforce, etc..)"
- aidenn0 13y ago>A manual on workflows does not come pre-installed with git, but maybe it should seeing how many people have questions on the topic. git help workflows
- skuunk1 13y agoInterestingly enough, I was just documenting my team's workflow in my blog... http://www.skuunk.com/2014/01/our-git-workflow.html http://www.skuunk.com/2014/01/our-git-workflow.html Very similar to this, but we add a couple of steps to allow a business owner to examine a feature before it gets accepted and also we use an integration branch to deal with merge conflicts before creating a releasable master branch.
- deleted 13y ago[deleted]
- peteratt 13y agoMaybe a stupid question, but I am not clear on what happens if, in between you send a pull request and the code is merged with master, the master branch itself gets modified. In that case you couldn't rebase and you could have merge conflicts with master, or am I missing something?
- bashcoder 13y agoThe main problem I have with this workflow is step 6, after a pull request has been approved: > (At this point if you have rewritten the history of a published branch and provided that no one else will commit to it or use it, you might need to push your changes using the –force flag). I don't think it's a great idea to institutionalize what most would agree is a Bad Git Practice, especially in a multi-user environment.
- neurostimulant 13y agoThe blog is down at the moment (returning http 503). Here is the cached version: http://webcache.googleusercontent.com/search?q=cache:https://blogs.atlassian.com/2014/01/simple-git-workflow-simple/ http://webcache.googleusercontent.com/search?q=cache:https:/...
- pmorici 13y agoTypical. They can't even keep their own website up. I had to use some of there tools in a job I had once and they were not reliable at all.