Teamwork & Git - Computerphile

Computer says no! What if two team members try to edit the same file in a project? Git has you covered - Dr Max Wilson explains how teams collaborate using Git.


This video was filmed and edited by Sean Riley.

[franchello]

We were never taught how to use Version Control in college. I think this is something you should lean to do in a first year CS course.

[YashKMusic]

It's hard to talk about Git without showing code to visualize the concepts - especially the part where the merge conflicts were mentioned

[matka_pluku]

I really love the work all of you are doing, and thank you so much for letting us being a part of it! I think it would be awesome to continue the git series with a video on git-annex. I think it is a really cool concept and would love to see you people breaking it down for us!

[ScottLahteine]

Version Control in-general is such a great and vital boon for development teams. I've become a huge fan of Git and GitHub, which have made it possible for me to maintain a big and popular project (Marlin Firmware) from anywhere, with a huge number of contributors, and even to get a little sponsorship so I can do the work full time. Before these services came along open source project management was a lot more scattered among a myriad of tools and servers.

2:28 — I tend to use 'git rebase' whenever I can, if the thing I'm working on can be done that way without a force-push. It keeps the history a little neater.

[ancientswordrage]

This is a lovely idealised view of teams and their processes.

[python-programming]

This is another great video in this great series!

[justsurajp]

these git videos are really great! as a dev who frequently works closely with git, i can really correlate with the video. however it would make much more sense, or complete sense, only when more hands-on examples are shown in the video. all theory and no examples, makes jack a dull boy! ;)

[TAPa]

As usual, permissions and backups prove once again to be two of the most powerful tools in the security toolbox

[briancoverstone]

During a merge conflict, if you want to also see the original code before both sides clashed, which can sometimes make it easier to merge, run the following before you do a git pull:
git config --global merge.conflictstyle diff3

[kristoffseisler]

what flavor of marshmallows the camera guy is chewing on?

[levmatta]

This brings us to a great truth of our trade -- always commit first (I actually use SVN).

[cppguy]

This is a great explanation on the high level. I would add that as your company grows, you break up large files into smaller ones, to minimize conflicts between edits. It's also the job at someone higher up to design the file system. When you decide what goes to which file you have to consider not just similar functionality, but also what's stable versus constantly changing, and what's private implementation versus customer-facing. Sometimes you have a different reviewer for the customer-facing interfaces, and a different person is going to review your Android code, iOS code, Windows code, Linux code, Web code, etc. And sometimes your code needs to pass auto-validation (such as circleci) before you're allowed to merge/pull.

[mdsajaldeowan]

thank you so much this is a beneficial video

[menachemsalomon]

My weirdest merge (with admittedly limited experience) was a SQL statement. Both of us had added columns, where Git noticed a conflict. But we'd also both increased the number of GROUP BY columns, which were numbered rather than named, so we both added ", 24" to the list - which was not seen as a conflict (and there were enough JOINs to make that change out of context). So I had to manually add ", 25" to the merge commit.

But that's what tests and test environments are for.

[DaveParr]

Seems like another part of the answer about YouTube hypothetically changing something is automated testing and having a test environment before they put the updated software into the live product?

[ZTST]

Hoping we might get a video about Git Merge vs Git Rebase.

[SArthur]

1:46 that's more like how svn works rather than git. git treats commits as atomic, rather than svn's file-by-file approach, so it'll be much simpler. if the remote branch has newer commits that your branch doesn't have, it will force you to update.

[willis]

I love git and I love collaborating, but man conflict resolution always feels like pulling teeth. I know it should be addressed at a higher level (try to structure parallel tasks that result in fewer conflicts), but I feel like the default tooling of conflict resolution in git is painful.

I'm all for CLIs, but I would much prefer a GUI for conflict resolution. Something like winmerge where I click on the lines I want to keep. Having to nano through files and delete lines and keep track of things and then think "oh I do I want to do an add now or not?"... it's all so much and I don't think it needs to be.

[bbb]

I am litterally in this every single day, but I am still inclined to watch the video.. huh

[DanielVoyles]

How many times did you hear "beata" before you realized he was saying "beta"?