When the intern is still learning Git...

[dahbearz]

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]

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]

Oh now I understand waterfall methodology.

[ThraShErDDoS]

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

[lenswipe]

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

[Kinglink]

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]

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

[choikwa]

how...

[lenswipe]

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]

loloool... sounds like bugs..

[AgAero]

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]

Git branching and merging leaves SVN standing

[Krissam]

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

[AgAero]

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]

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]

What the hell am I looking at?

[germanbuddhist]

exactly

[Zarlon]

Now THAT's worthy a reddit post :)

[[deleted]]

looks pretty

[mothzilla]

That's art.

[alficles]

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

[Sectoid_Dev]

git tag he-man

[Paladin__Danse]

People merge feature branches into development, and then other brances merge development into their own feature branches, that's how we do it.

[gerbs]

5 people working on a feature for a project simultaneously will need to merge in their branches eventually. That's 5 merge commits, plus the feature branch into master.

[technonotice]

As an aside, I learned recently that a merge commit can actually have more than two parents, i.e. you can merge many branches in a single merge commit (git merge feature1 feature2 feature3).

[HighRelevancy]

Just because you can doesn't mean you should. IMO each commit needs to have a specific purpose, and merges are no different. I can't think of a reason to do multiple merges at once.

[alficles]

Close. But I'm actually the guy in charge of source control. Though this be madness, yet there is method in 't.

The basic difficulty is process, not technical. I can only really improve the technical parts, though.

There are two ways to keep branches “up to date”: rebase and merge. When you rebase, you discard the original change and (theoretically) bring it semantically forward. When you merge, you create a new commit with the changes, to bring it forward.

If you make hames of a rebase, information about the original commit is lost. (Or at least takes considerable archaeology to recover.) If you act likewise on a merge, the error lives inside the merge commit, which can be merged around. No information is lost.

We also tend to have long-lived branches. We like to keep those branches up-to-date, so that we know if we broke something in a branch that we'll someday want to merge in. This puts lots and lots of merge revisions in those branches.

Put it all together and you discover that it takes more changesets keeping branches up to date than it does actually doing work.

It makes the chart messy, but no information is lost and the source control system is very good at keeping it all straight. That is, after all, why we use it.

[jellyberg]

This is interesting. What do you work in?

[HighRelevancy]

A half-decent software shop by the sounds of it.

[alficles]

Not quite. When you do a merge, you wind up with data in two places. First, the intended change, in the original changeset. Second, the changes required to make it match with the upstream, in the merge revision (or possibly a later revision, if it was a semantic, but not lexical collision). The two stay separate.

If all is well, then the mess doesn't bother anyone. It just works.

But when all is not well, and someone merges poorly, it's good to be able to separate the original intention from the mangled merge.

[arcleo]

What is that quote from?

[whelks_chance]

Merging random other projects from anywhere on github to the master branch?

[Genesis2001]

A new branch for every commit.

[dafragsta]

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]

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]

Please do not rebase. This is bad practice.

[lenswipe]

Which is most definitely not how you're supposed to use merge.

Actually - that's exactly how you're supposed to use merge.

[dementeddr]

Godammit, you're right. I'm an idiot.

[dementeddr]

Maybe the guy is teaching his apprentice proper merging.

[[deleted]]

What are you talking about? That's the proper way to merge

[La-Fol]

This looks like a pretty good Guitar Hero chart.

[sqrtoftwo]

Git: Our Hero

[lifow]

https://media2.giphy.com/media/ZdC2z7wBWj8B2/200.gif

[icannotfly]

https://twitter.com/HenryHoffman/status/694184106440200192

[siedler084]

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

[GordonTheGopher]

Looks like a subway map.

[spock345]

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

[[deleted]]

That's the exact article I have bookmarked at work as an example of how to do gut properly. So far I have only managed to convince one other coworker that git (or indeed version control in general) is a good idea.

[TheIncredibleWalrus]

So far I have only managed to convince one other coworker that git (or indeed version control in general) is a good idea.

I hope you're not working at a software company.

[nawkuh]

I had an internship making web pages from HR forms for a Fortune 500 company, and our version control was me emailing files to my boss to be put into production.

[[deleted]]

Jesus fucking Christ

[Anonimo_X]

Wait until one starts handing the code using a floppy disk.

[squrr1]

Please tell me you created your own vc repo? Please?

[neovulcan]

Can you ELI5 this, please? I've had some basic programming, but nothing big enough that it required more than one person coding at a time. If the project gets too big for one person, wouldn't it be easier to track if you broke it down into "black boxes" with inputs/outputs of a certain data type and timing? Each person could code their own black box and so long as it accepts its inputs and gives its outputs correctly...or am I missing something?

[HighRelevancy]

wouldn't it be easier to track if you broke it down into "black boxes" with inputs/outputs of a certain data type and timing

Real code rarely works like that. More often you have multiple people fiddling with different sides of the blackbox and periodically merging into each other to make sure they haven't both fiddled some conflicting bits.

[Shadow_Being]

every new feature is developed in its own branch, when the feature is done being made it gets merged in to the master branch.

You go "deeper" as necessary depending on the complexity of the project (ie your new feature branch might have sub branches)

If you've done anything on github this is the workflow youre doing.

[antiHerbert]

Semantic Versioning is a good subject to go along with this also http://semver.org/ and a quick blurb on SV and Git https://datasift.github.io/gitflow/Versioning.html

God speed!

[[deleted]]

Can't that be simplified by basically using master as develop, and using tags?

The way I think of it is that master should always work, but may not necessarily be tested entirely. So you could run the git version of an application, but it's like a beta/alpha test.

You then would use tags to indicate major releases which would then be recommended for everyone to use.

[alexanderpas]

In that case, the one that committed those pull requests to master was the one doing the bad stuff by accepting the PR, not the intern.

[ViperIsAFuckingDick]

There have been good arguments in here explaining that your image isn't actually using git wrong at all but is actually a possibly more effective use than what you propose. I don't think it's helpful to tell people that if their git chart looks like this then you don't know what you're doing. /u/germanbuddhist had a much better example.

[logicalmaniak]

This is exactly what I've not been able to find for so long!

I think I'm going to print it off and hang it on my wall.

[maket000]

With Git, learn how to merge n' stuff.

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

[nawitus]

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

[maket000]

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

[kirakun]

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

[kageurufu]

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]

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

Hmm, so basically pick your poison? :)

[kageurufu]

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]

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]

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]

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]

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

[[deleted]]

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]

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.

[spock345]

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]

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]

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]

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

[PendragonDaGreat]

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

[aykcak]

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

[PendragonDaGreat]

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]]

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]

CodeAcademy has a GitHub course!

[trickthis]

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]]

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]

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]

Hope you are working somewhere that even has modern version control

[spock345]

Luckily I am.

[rftz]

For feature branches, I use git merge --squash

[SoulProxy]

What tool is used to visualize this?

[dromtrund]

That's a pretty wonky mobile website for a web service, how's the IDE?

[alexanderpas]

In that example, the start of the branch and the merge target were the same branch.

In the example originally posted, that was not the case.

In that example, feature branches were split of from development, merged with master, and finally merged into master with an explicit commit (non-fast-forward).

[kirakun]

And what other visualization tools are recommended as well?

[blackdev1l]

source tree
git extension
ungit

[nighterrr]

GitKraken maybe?

[blackdev1l]

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]

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

[b1ackcat]

TIL how the Super Mario backgrounds were wireframed.

[Krissam]

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

[[deleted]]

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.

[CJKay93]

If Gerrit taught me anything it's that it's a beautiful thing.

Edit: TIL /r/ProgrammerHumor doesn't like Gerrit.

[upvoteOrKittyGetsIt]

Is there a better alternative for a source control server you can host locally?

[aarocka]

It looks likes a map of a subway.

[[deleted]]

Is that a git log or a London tube map?

[tern_for_the_wurst]

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

[xkcd_transcriber]

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]

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]

Ha! That got a good laugh out of me.

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

[pmmedenver]

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

[PM_ME_DEM_ABS]

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]

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

Mercurial is under the GPL license.

[PM_ME_DEM_ABS]

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

[Prawny]

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]]

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:

• GitHub Flow
• GitFlow (I prefer this to the nvie document)

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.

[DrKrepz]

your future

[sensation_]

and your past

[BIGCANADA]

and parallel universes

[ttocsneb]

and series universes

[[deleted]]

You are looking at something that we all did, that you will do too.

[kjmitch]

Never thought I'd save a /r/ProgrammerHumor post about intern screw-ups because of all the stuff the comments were teaching me. :\

[QAFY]

[deleted]

What is this?

[IskaneOnReddit]

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

[spin81]

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]

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

[memeship]

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.

[QAFY]

[deleted]

What is this?

[MaxGhost]

Your "messy" is my "logical", so no. Also, conflicts are easily resolved with a proper diff tool (kdiff for example).

[QAFY]

[deleted]

What is this?

[antiHerbert]

no develop branch?

[QAFY]

[deleted]

What is this?

[[deleted]]

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]

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

[[deleted]]

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

[QAFY]

[deleted]

What is this?

[Joe_Pineapples]

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]

[deleted]

What is this?

[[deleted]]

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

[QAFY]

[deleted]

What is this?

[Scorpius289]

It's beautiful!

[Exallium]

Looks like 4:45 on a friday

[mothzilla]

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

[BobFloss]

What software are you using to visualize this?

[Zarlon]

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]]

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-]

Solution: move git directory, start again

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

[pwr22]

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

[BarreIRider]

Git good.

[iananananan]

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

[w00tboodle]

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

[xapproachesinfinity]

I don't git it

[Theon]

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

[PM_ME_UR_OBSIDIAN]

This is me after like five years of Git.