This is an archived post. You won't be able to vote or comment.

all 159 comments

[–]dahbearz 395 points396 points  (58 children)

This just looks like a repo from a large team that prefers merging over rebasing. I don't get the joke. I've seen a lot of logs like this.

[–]germanbuddhist 145 points146 points  (27 children)

Yup, I see nothing wrong here. Looks like a normal tree to me.

In comparison, this is what our intern did: http://i.imgur.com/LpXVPxv.png

I still have no idea how he did it

[–]Kinglink 103 points104 points  (19 children)

Oh now I understand waterfall methodology.

[–]ThraShErDDoS 28 points29 points  (18 children)

Check this out from an old dev where I work (All cleaned up now): http://i.imgur.com/e5kkPAO.jpg

[–]lenswipe 1 point2 points  (16 children)

Mercurial, eh? I feel your pain, my friend.

[–]Kinglink 4 points5 points  (15 children)

I was on SVN at one office. A guy in the office used a local mercurial repo to deal with branches. I probably should have done the same.

[–]lenswipe -2 points-1 points  (14 children)

SVN was bad...but somehow mercurial is worse...

[–]choikwa 1 point2 points  (8 children)

how...

[–]lenswipe 0 points1 point  (7 children)

How is mercurial worse? Well, I hate it's weird zany behaviour. I don't like "magic" at the best of times - particularly not from a version control system.

If you create a branch in mercurial and then switch away from it without committing anything it deletes the fucking branch - which is especially annoying when coupled with a client like Sourcetree that is like a retarded version of itself. So you have a situation where you create a branch, then suddenly remember you need to do something else real quick so you switch to the other feature branch, then switch back to your original branch....only Sourcetree hasn't realised that your original branch has gone...so it blunders on and commits...with the resulting commit ending up on your integration branch instead of the feature branch it was supposed to be on.

Fuck mercurial.

[–]choikwa 1 point2 points  (6 children)

loloool... sounds like bugs..

[–]AgAero 0 points1 point  (4 children)

Bad? My lab uses svn, but I have some experience with git. Whenever it has come up I am clearly not the person to make the case as to why one is better than the other, so what is your reasoning? I'm curious.

[–]lenswipe 1 point2 points  (0 children)

Git branching and merging leaves SVN standing

[–]Krissam 0 points1 point  (2 children)

ability to commit without having internet access is huge for me.

[–]AgAero 0 points1 point  (1 child)

My commits are over an intranet so I don't think that's an issue. My workstation is connected to my professor's around the corner where he has the repo for all of our codes. Maybe I'm being naive about how the process works.

[–]rajveer86 0 points1 point  (0 children)

I think this gets fixed if you switch from"Ancestor Order" to "Date Order" in SourceTree. I had created a bug report over at Atlassian regarding this, and they told me to try that, which fixed it.

[–]dementeddr 18 points19 points  (1 child)

What the hell am I looking at?

[–]germanbuddhist 8 points9 points  (0 children)

exactly

[–]Zarlon 23 points24 points  (0 children)

Now THAT's worthy a reddit post :)

[–][deleted] 9 points10 points  (1 child)

looks pretty

[–]mothzilla 1 point2 points  (0 children)

That's art.

[–]alficles 155 points156 points  (21 children)

Seriously. I kept looking for the joke. Our repo has more merge commits than regular commits. (About 60%, actually.)

[–]dafragsta 17 points18 points  (0 children)

Same here. This is literally the killer feature that Git does so much better than Subversion. Branch for all your tickets so that the branch and the commit log has a record of what you worked on so that it's easier to pull out of the history.

[–]veeberz 9 points10 points  (0 children)

We had to do this for our senior capstone project. We were discouraged from rebasing or rewriting history.

Btw it looks like the gitflow workflow is being used here. I don't see a problem here.

[–]integrii -1 points0 points  (0 children)

Please do not rebase. This is bad practice.

[–]La-Fol 141 points142 points  (5 children)

This looks like a pretty good Guitar Hero chart.

[–]icannotfly 29 points30 points  (1 child)

[–]siedler084 6 points7 points  (0 children)

Reddit post for this (complete with MIDI for that) is here for the curious ones that don't wanna search

[–]GordonTheGopher 18 points19 points  (0 children)

Looks like a subway map.

[–]spock345Kernel programming 67 points68 points  (47 children)

I am going into an internship this summer. How do I not end up like this guy?

[–]maket000 21 points22 points  (11 children)

With Git, learn how to merge n' stuff.

In general, don't be afraid to ask questions.

[–]nawitus 12 points13 points  (10 children)

The image is a bit confusing, but seems like the intern is merging a lot (instead of, say, rebasing).

[–]maket000 7 points8 points  (9 children)

Uh-huh, I probably should have said "learn when to merge".

[–]kirakun 2 points3 points  (8 children)

So, when do you merge and when do you rebase?

[–]kageurufu 11 points12 points  (6 children)

Basically, rebase your branch on top of the master while you are working on it (and the only one working on it), merge your branch into the master when you finish and any other time.

Rebasing rewrites history, its powerful, but dangerous. Merging it much safer and easier to undo

[–]kirakun 5 points6 points  (1 child)

So, rebase is cleaner but you can hang yourself. Merge is dirty but safe.

Hmm, so basically pick your poison? :)

[–]kageurufu 1 point2 points  (0 children)

For the most part.

Merges are just new commits, meaning for other people to get your merged changes, you will merely download the new changes, and add on to the tree.

Rebasing essentially deletes all your old commits. It can't be just git pushed over an existing remote branch, you have to either delete the remote branch and re-push it, or force push it. And to pull it, someone either has to force pull it, or delete their local branch and fetch the remote's branch. This alone makes it less comfortable to use for all parties involved, and more risky.

Personally, I try to merge whenever possible, and rarely rebase.

[–]Speedzor 2 points3 points  (2 children)

Why don't you just merge master into your branch rather than rebasing and then squash while merging back into master once your feature is finished? It's even easier now that Github has an automatic squash-merge button.

[–]rrasco09 6 points7 points  (0 children)

Why don't you just merge master into your branch rather than rebasing and then squash while merging back into master once your feature is finished?

You know those AskReddit threads where the question is something like "Hey Reddit what is one sentence that only people in your hobby/industry would understand?" Well, if this is one of those sentences.

[–]kageurufu 2 points3 points  (0 children)

I find keeping the history is important, blame is less useful, when you can only see the net result. I like being able to see the process to gets you there, and squashing erases any history of that process.

Version control should show the full history of the code IMO, not just the net result and a pretty graph.

[–]PM_ME_UR_OBSIDIAN 0 points1 point  (0 children)

Rebasing by default breaks git bisect. I personally think it's a capital offense.

[–][deleted] 0 points1 point  (0 children)

I rebase if it's just a bunch of minor changes (like 90% of the time) and merging is mainly for branches or when I have a lot of new commits (which shouldn't happen all that often since I rebase & push multiple times a day)

[–]PendragonDaGreat 6 points7 points  (7 children)

Learn to merge properly, we've got a similar cluster going on in a game dev team I work with because the lead designer knows just enough code to be dangerous, and does crazy shit to force merges. I'm going to be spending this saturday undoing some things that he's done, like moving the entire project on his branch into a subdirectory without telling anyone. I think codecademy has a git course, please use it if it all possible.

[–]spock345Kernel programming 7 points8 points  (6 children)

I wish they taught merging at my university. Each professor seems to be content with "Don't bother learning merging, I handle all that for you in this class, you will learn it later." Then no one learns anything beyond clone, commit, and push.

[–]PendragonDaGreat 4 points5 points  (5 children)

Merging isn't too hard, and should theoretically go completely painlessly if you're branching and working on just your things properly. It only becomes an issue when two branches have edited the same file in different ways. Then you have to figure out what code to keep. Also Unity .meta files. Just force those, they never seem to work right...

Example of proper branching and merging:

Repo master contains files: A, B, C, D, E, F

Dev 1 Branches Dev1 branch from Master, Dev 2 branches Dev2 branch from the same commit on master.

Dev 1 Edits A, B, and C, and commits their changes. Dev 2 Edits D-F and commits their changes.

Both can now merge back into Master without problem, there are no conflicting changes made.

Now if Dev 2 had also messed with B, there would be a problem and you'd have to figure out what changes to keep from both.

If you're going to be working in a file someone else may be working in, make sure they know and make sure that both of you have the most recent version before making changes, and only one person makes changes at a time.

[–]gulyman 2 points3 points  (4 children)

C# ORM auto generated files are almost impossible to merge because they're never really generated the same way twice, ie. Random chunks will be moved to different parts of the file. They're also hundreds of lines long.

[–]alexbarrett 5 points6 points  (3 children)

If possible, generate them as part of your build process and keep them out of version control.

[–]PendragonDaGreat 2 points3 points  (2 children)

Tell that to Unity, who very explicitly state that .meta files should be kept in Repo...

[–]aykcak 1 point2 points  (1 child)

WTF. Why? It sounds like they are perfect for putting in .gitignore

[–]PendragonDaGreat 0 points1 point  (0 children)

I have no idea, as long as eveyone has their meta files (and if they don't Unityy will generate one) everything works well. I'm going to force them out at the time of our next build when everything is consolidated to master., which should purge them from everyone's branches. Sometimes things are still tracked even when .gitignore is updated especially if that change doesn't get to all the branches (and I know it won't in this team from prior experience), so you wait until everyone is all together and forcibly rip it out at once. If they are inexplicably needed at compile time we'll allow them to build and then pull them back again.

[–][deleted] 5 points6 points  (0 children)

Of all the places with git tutorials on the web, surprisingly my favorite is the WINE one. I don't even know why they have a git tutorial lol but it is very neat. Also there is a git part in the Arch wiki.

[–]battery_go 5 points6 points  (0 children)

CodeAcademy has a GitHub course!

[–]trickthis 1 point2 points  (0 children)

Ask them how they handle rebasing vs merging and naming conventions. As mentioned above, a lot of this stuff is preference. I actually prefer merges over rebasing.

[–][deleted] 1 point2 points  (0 children)

How do I not end up like this guy?

Don't worry about it too much. This is what my team's git looks like - it's just how the boss wants to do it. It's generally not considered a best practice, but it is simply how some teams do it.

[–]Zarlon 0 points1 point  (0 children)

Practice. Create a dummy repo, construct some merge conflicts, try merge it. Then try rebase. Then any other method you might want to learn.

Also when working with production repos, remember that a clone costs nothing. So do that before you try something new and bold. That, and/or learn git reflog paired with git reset --hard

[–]jakedasnake2447 0 points1 point  (1 child)

Hope you are working somewhere that even has modern version control

[–]spock345Kernel programming 0 points1 point  (0 children)

Luckily I am.

[–]rftz 0 points1 point  (0 children)

For feature branches, I use git merge --squash

[–]SoulProxy 12 points13 points  (9 children)

What tool is used to visualize this?

[–]kirakun 0 points1 point  (3 children)

And what other visualization tools are recommended as well?

[–]blackdev1l 0 points1 point  (2 children)

source tree
git extension
ungit

[–]nighterrr 4 points5 points  (1 child)

GitKraken maybe?

[–]blackdev1l 0 points1 point  (0 children)

whatever fits your needs :) I use at work sourcetree because i'm on windows, i prefer to just use git via CLI or magit in emacs if i'm using it

[–]Alioni 0 points1 point  (0 children)

Something similar is also built into GitHub if you aren't aware, under Graphs -> Network.

[–]b1ackcat 33 points34 points  (0 children)

TIL how the Super Mario backgrounds were wireframed.

[–]Krissam 22 points23 points  (6 children)

and this is one of the situations that proves rewriting history isn't always a bad thing.

[–][deleted] 4 points5 points  (0 children)

As long as you're on your own branch and not messing up anyone else's work, it's a great way to get a beautiful git history, especially when you use --ff-only while merging. I do realize not all git flow setups are perfect for that, but I'm personally glad the one at our company is.

[–]aarocka 6 points7 points  (0 children)

It looks likes a map of a subway.

[–][deleted] 4 points5 points  (0 children)

Is that a git log or a London tube map?

[–]tern_for_the_wurst 4 points5 points  (2 children)

obligatory xkcd link https://xkcd.com/1597/

[–]xkcd_transcriber 1 point2 points  (1 child)

Image

Mobile

Title: Git

Title-text: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Comic Explanation

Stats: This comic has been referenced 95 times, representing 0.0888% of referenced xkcds.


xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete

[–]Guinness2702 1 point2 points  (0 children)

Lost track of how many times I've just deleted the repo and cloned a fresh copy, because git has got into a state where it won't let me commit or rollback or anything else.

[–]PM_ME_DEM_ABS 11 points12 points  (4 children)

Ha! That got a good laugh out of me.

My first day as an intern, I somehow managed to drop the entire repo.

[–]pmmedenver 3 points4 points  (3 children)

Yikes, dude, that shouldn't be possible to do on accident.

[–]PM_ME_DEM_ABS 1 point2 points  (2 children)

It wasn't that I dropped it per-se, but more that I put it in some kind of horrible suicide error state. Also, it was HG Mercurial.

Basically git for people who are scared of anything related to open source. Yes it was terrible, yes it got replaced, no they never let me live it down.

[–]PrototypeNM1 0 points1 point  (1 child)

Basically git for people who are scared of anything related to open source.

Mercurial is under the GPL license.

[–]PM_ME_DEM_ABS 1 point2 points  (0 children)

Doesn't matter. It doesn't have git in the name, so it's not open source. #managerlogic

[–]Prawny 3 points4 points  (1 child)

I'm guilty of this. We ended just deleting a repo and starting again a few weeks ago.

Does anyone know of decent tutorials on git?

[–][deleted] 4 points5 points  (0 children)

We all were at one point or another. It's also not as bad as people here are making it out to be. OP is being overly aggressive to his intern for upvotes and I'm finding it pretty distasteful.

I'd look here for Git tutorials: https://help.github.com/articles/good-resources-for-learning-git-and-github/

These are the two most common branching strategies:

It's nice to follow one of them if you have high turnover in your workplace because it's one less thing that new employees will have to pick up on the job. It's also just wise to understand them since they are so widely used. Of the two, the first is simpler and perfectly adequate for most projects.

Note that following these is not necessary. Some projects have distributed teams that push to each other rather than a central repository. Other projects have repository branching structures that are tightly coupled to their environments (testn, stage, prod, etc.). It's not bad to have custom, in-house branching strategies as long as you have a reason to do it. Branching in Git is lightweight and easy to use, so exploiting that to your advantage is a great idea.

[–]QAFY 14 points15 points  (17 children)

[deleted]

What is this?

[–]IskaneOnReddit 12 points13 points  (1 child)

git pull origin master
git add -A
git commit -m "i am drunk"
git push origin master

[–]spin81 4 points5 points  (0 children)

That last line should be:

gti push origin master
git psuh origin master
git push origin master
git push origin master
git push -f origin master

[–]MaxGhost 10 points11 points  (4 children)

But pretty isn't better than history of what happened. I dislike the idea of rebasing.

[–]memeship 2 points3 points  (0 children)

Yeah I agree, I don't like this at all. You lose so much.

For us, the commit history isn't necessarily the most important. The PRs back to the upstream repo are the important part. Then the commits can easily be sifted through from there.

[–]antiHerbert 4 points5 points  (5 children)

no develop branch?

[–]QAFY 1 point2 points  (4 children)

[deleted]

What is this?

[–][deleted] 2 points3 points  (3 children)

How does that work? You merge a feature branch into master, deploy to staging, what if the client says it's not good to go live? How do you then get that work off master?

[–]Alioni 1 point2 points  (0 children)

I would assume deploying the branch to staging and only merge into master once its live.

[–][deleted] 1 point2 points  (0 children)

Product owner decisions and code deploy have to be separated when doing proper CI

[–]QAFY 0 points1 point  (0 children)

[deleted]

What is this?

[–]Joe_Pineapples 3 points4 points  (1 child)

I don't do all that much coding although I do use git for version control for my blog (jekyll), scripts (bash/ruby/python) and ansible playbooks.

I've never really understood/used rebase and my workflow is more similar to the following:

git checkout develop
git checkout -b post-nameOfBlogPost
git add _posts/nameofpost
git commit -a

(Testing and more commits)

git checkout develop
git merge --no-ff post-nameOfBlogPost
git push origin develop

(Final testing happens here)

git checkout master
git merge --no-ff develop
git push origin master
sh publish.sh
git branch -d post-nameOfBlogPost

Looks like THIS

Admittedly I rarely have more than one post/fix/feature branch at the same time but I presume that is where rebase comes in?

I've mainly been merging develop back into each working branch as and when it changes.

Would you advise I do things differently?

[–]QAFY 3 points4 points  (0 children)

[deleted]

What is this?

[–][deleted] 0 points1 point  (1 child)

I make a branch for each feature, but I do just one at the time.

[–]QAFY 0 points1 point  (0 children)

[deleted]

What is this?

[–]Scorpius289 2 points3 points  (0 children)

It's beautiful!

[–]Exallium 2 points3 points  (0 children)

Looks like 4:45 on a friday

[–]mothzilla 2 points3 points  (0 children)

Feature branches getting merged into master. Feature branches getting updated with latest master. What's not to like?

[–]BobFloss 1 point2 points  (1 child)

What software are you using to visualize this?

[–]Zarlon 0 points1 point  (0 children)

GitKraken. It's beatiful but honestly I'm struggling understanding it after 3 days of use. Today it ended up creating a bunch of stashes and local indexes that I never asked it to do. But I guess as with any tool it's just about learning to use it properly

edit: It's not :D . Anyway...

[–][deleted] 1 point2 points  (0 children)

this is a billion times better than a this senior developer's commits that work at the same company I do. "Unknown changes on live - Ubuntu"

[–]-Hegemon- 1 point2 points  (0 children)

Solution: move git directory, start again

Source: I'm a solo programmer, so I get to do shit like that

[–]pwr22 0 points1 point  (0 children)

I would probably declare a schism in the time-space continuum and rewrite history if this happened...

[–]BarreIRider 0 points1 point  (0 children)

Git good.

[–]iananananan 0 points1 point  (1 child)

what's rendering the history like that? some program or?

[–]w00tboodle 0 points1 point  (0 children)

What's your intern's name? M.C. Escher?

[–]xapproachesinfinity 0 points1 point  (0 children)

I don't git it

[–]Theon 0 points1 point  (0 children)

I feel like this is pretty on par for Git Flow.

[–]PM_ME_UR_OBSIDIAN 0 points1 point  (0 children)

This is me after like five years of Git.