Why is git so unintuitive? Fuck.

is it? I got the hang of it quickly and I am a wintard. whats your excuse

learn its data model, and exactly how the commands operate on that data model, and it will make perfect sense.

>>61944962
OP is a mactard

>>61944957
just get a paper and a pencil and draw commit trees. Look what push, pull, rebase, cherrypick, reset do to the position in that tree. If you have that in your head everything else is easy

>git add
>git commit
>git push
>git pull
wow that was hard

>>61945176
>merge
>rebase
>merge conflict
>submodules
FUCKING SUBMODULES

gitk to visualise the tree

>>61945189
Either use git flow or an IDE with integrated git support, gee that was hard

File: 2-girls-laughing-AMGH88.jpg (153KB, 1300x956px) Image search: [Google]

153KB, 1300x956px

>>61945189
>using submodules
>any year

Are you trying to learn git and how to upload shit to github at the same time? That makes things more confusing. Focus on local repos first.

>>61944957
Word my man.
Still can't get the hang of branching and merging after 4 months in pro webdev position.

>>61945176
>git rm -rf /

>>61944957
torvalds made it, what do you expect?

>>61945373
This is why everyone hates webdevs, kys
t. backend webdev

Read that https://git-scm.com/book/en/v2 and stop complaining. I'm not even in compsci or anything related and I was at ease with git in a few days.

>>61945373
>>61944957
Watch "git for ages 4 and up" on youtube. It's long but honestly really good

git hub? exactly man, i looked at it two or three times across a year and saw no download button after 15m of looking at it so gave up until trying way harder next time

>>61944957
it was made by one guy in between kernel patches and fap sessions

>>61944957
>unintuitive
>>>/babby/

I used to think submodules were cool

oh I was so wrong

so fucking wrong

>>61945373
Webdevs are the babbys of people who write machine interpretable text (because I refuse to call it code)

Just give it time OP. Git can be tricky to understand based on your previous experience but with enough time and effort you'll surely pick it up. Once you get over that initial hump it's all quite intuitive and pretty neat.

There have been some decent suggestions for learning resources in the thread. Once you understand the basics and how it's actually working to put Git into practice it would be good to look into common workflows. Check out GitFlow when you're ready for that, it'll give you an appreciation for why Git is cool.

Don't give up!

because you came here to cry about it instead of studying it some more like an educated person who went to school and made good grades would do.

>>61944957
Because it's for version control and you're using it for backing up your dot files. You're not a programmer, you're a sysadmin. Don't use programmer shit. You won't understand it.

I understand that some people have performance or permission constraints, and others just feel cooler using terminal commands, but I find that a GUI makes git so fucking straightforward.

>>61949011
>projecting

>>61948950 don't forget to tell this
>>61944957, stop crying, grow up, and read the bible

https://git-scm.com/

File: it's_dogshit.png (48KB, 330x478px) Image search: [Google]

48KB, 330x478px

Use fossil or mercurial.

>>61945281
what's wrong with submodules?

>>61944990
What a crap of an excuse for a poorly designed API. The API should reflect the functionality not the implementation details.
As a user I don't need to study shit. I don't mind if it is implemented with red-black trees or unicorn poo for that matter.

>>61949482
Never understood the difference between git and mercurial

>>61949623
You don't need it. Just:

1. Use an actual package and dependency manager/injector

Or

2. Include the fucking think directly to your repository

>>61945016
>>61945189
You don't need fucking rebase. That's historical revisionism in its purest form.
If you need a proper change log find another way to record/manage changes, but don't fucking mess with the timeline of events just to have an acceptable log at the end of the day.

>>61944957
git gud git

>>61949693
Hg has a proper CLI, each command does one thing and only one. Git is more "flexible". Messing with history is forbidden by design WHICH IS A GOOD THING.

>>61945718
>git-scm.com
>git-scm
>scm = scam
so git was a scam all along...

I always had my suspicions.

File: 1310096653022.jpg (127KB, 550x550px) Image search: [Google]

127KB, 550x550px

>>61946395
>the current state of /g/

Git is for gits.
Same goes for GitHub

Why?

Because of the name.

...

fools.

By the time you understand it well enough to make it more intuitive, it will seem incredibly intuitive to you. Thus no one who is able to make git more intuitive has any incentive to do so. Welcome to open source tooling.

>>61950041
By the time you become naturally inclined to walk around on your hands and knees, it will seem incredibly intuitive to you. Thus no one who is able to walk around on their hands and knees at all times has any incentive to make it easier for others to do the same. Welcome to your fallacy.

>>61944957
To keep out the women of course

>>61944957
>>61949668
CIA niggers want your cock in the cloud like they want your guns. Git is slavery.

>>61950121
kek

>>61945491
This!
>wincucks reporting in

>>61949841
No, I was very clearly someone who wasn't forced to use github and couldn't be arsed until it meant something to me

i had a question active in sqt was really all..

>>61952200
Lesson 1:
Git != GitHub

>>61944957
git gud

>Learned a little bit of git and github in my spare time to help with various game-related projects
>Apply for QA internship, get interviewed and mention using git and github
>Get the internship
I barely knew much of it and turns out my work just uses tortoisegit so all I have to do is right-click commit, right-click pull, and finally right-click push. I don't see what's so hard about that.

>>61949722
Fuck off brainlet, rebase is the only way to fly.

>>61953060
You, sir, are the actual brainlet. Pen and paper is the only method that truly intelligent people use to monitor and manage product versions.

>>61944957
Because a lot of coders never heard of UX design and just make stuff that makes sense to someone who already knows how it all works

>>61944957
it's made in the philosophy and spirit of Unix, all that shit is unintuitive because it has 50,000 options and 40,000 of them haven't mattered in the last 25 years
if you want I could link my notes on it

>>61945176
>pulling
>instead of fetching and then merging
you fool

>Literally the only commands you will ever use
>pull
>push
>fetch
>merge (-X theirs/yours)
>history
>status
>diff (path)
>checkout
>branch

A few weeks of using it and you will be fine. Why cry about it instead of just trying to get good and remember.

>>61948858
>machine interpretable text
>he programs directly in binary, using the hex mode of his favorite editor
Is there a worse hell than this? Apart from being a JS programmer?

>>61945373
Just fucking use the git flow scripts and stop shitting up my history.

>>61949482
I somehow managed to delete my root commit, even caused git to segfault when trying to do repairs with various commands. One of the senior engineers who is basically the git master around the office had no clue what I could have done to cause it or how to fix it. This comic ended up being my solution.

>>61949482
this is true with almost all source control programs and local copies

>>61946395
I'm going to save this it's excellent bait :D

>>61955326
You must've only used shit like CVS and Subversion so far, anon.

>>61952229
Thats not a lesson at all, i've learned nothing

>>61954037
>rebase
>blame
>reset
>--amend
>stash
> cd .. && rm -rf that-repo && git clone url-of-that-repo && cd that-repo

>>61949722
you literally have it backwards. rebase by default

File: mercurial.png (16KB, 303x364px) Image search: [Google]

16KB, 303x364px

>>61944957
git is bloat, use mercurial

File: 1497585740744.jpg (59KB, 400x571px) Image search: [Google]

59KB, 400x571px

>>61950121
GOTDAMN

>>61946395
have you tried that big green button "Clone or download"?

>>61944957
Because it was written by Linus Torvalds

File: 2462524.jpg (20KB, 306x306px) Image search: [Google]

20KB, 306x306px

>start from main branch
>create new branch for develop
>create branch for each developer
>assign each developer different but well defined tasks to minimize potential conflicts
>when developer finishes a major feature that needs to merge with develop branch, he will do so
>resolve any possible conflicts
>create other branch for that developer to continue developing other feature

70% of the work is by coordinating yourself with your co-workers.
It's not that hard.

>>61955844
what happens when developer A merges with head and something breaks when developer B finishes their part and tries to merge? or are they merging to different main branches?

>>61955844
Don't you mean forks?

>>61955844
Doesn't the main branch get replaced with the merging branch when you merge?

What would be the point of having different people working on separate branches?

Why not work on the same branch?

What is the optimal method to "merge" branches?

What is your experience with "merging" branches?

File: Untitled.png (65KB, 1228x529px) Image search: [Google]

65KB, 1228x529px

>>61955772
You mean the small plaintext grey "download zip" button?

>>61959692
>gist

>>61949668
>poorly designed API doesn't matter
>poo in the loo develops some awful system that catches fire the second you use the well-named cli commands wrong
API matters like your skeleton being in the right places matters.

if you hate git so much then just use mercurial or whatever

>>61944957
>Why is git so unintuitive? Fuck.
guy who wrote it is an autistic idiot savant.

>>61952229
>>61955689
when explaining to the non-/g/ (which is most of /g/ atm honestly), avoid using programming colloquialisms because they won't get it.

>>61944957
why are you using change control without an idea of how you want to control your changes?

File: 1487502449920.jpg (25KB, 641x530px) Image search: [Google]

25KB, 641x530px

>>61959731
>the well-named cli commands

>try and pull
>merge conflict
>try and merge
>files end up filled with junk characters
Couldn't use a copy eh Linus? Had to fuck up all my code???

File: Girls[1].jpg (77KB, 600x536px) Image search: [Google]

77KB, 600x536px

>>61959772
>not keeping backups and relying on your source control

>>61956204
you resolve merge conflicts when they appear and also don't work on things you are not assigned on without letting other people know. properly designed, unit-tested software will not have this problem unless your developers are retarded.

>>61959220
>github

>>61959287
for all intents and purposes, but not really. merging is as it is stated: you MERGE the contents of the branches, not overwrite. the commits to the main branch stay when merging, and the newly added commits that you are merging in are---wait for it---merged with the other branch so that everything goes together. when edits collide it is called a conflict, which should be resolved.

to prevent conflicts. you keep one feature to one branch to easily visualize what work has been done and to keep the main branches clean.

see above. it is fucking painful, especially when others work on the same files as you (which shouldn't be happening at all if the first of the above is true)

try to merge and wait for git to tell you if you have conflicts. if there are, resolve them or ask the person working on that branch to resolve it, either alone or by talking with the other developer that was working on the conflict.

merging is fine when there are no spergs. it's just taking the work that was done on the branch and moving it over. that's it.

please consider reading some git tutorials, or git-scm handbook.

>>61959756
I'm being optimistic. of course the poo won't actually make well-designed commands, it was more an example of how a poorly designed backend can fuck up a well-designed frontend.

>>61959823
Can't you just design a merge protocol where people working on branches operate on class files which only they are working on? They could modify other components for testing without interfering with the main branch.

Do you have much (real-world) experience with developing based on branches? What kinds of issues are there usually? Do merges usually go well or are they difficult?

>>61959993
>class files
telling, anon.

what you said doesn't make much sense. the point of having a branch is to have someone or a group of someone's work on a point in the software's development cycle where a feature needs to be added, and stability of the software (preexisting bugs not included) is required, meaning no one else messing with the codebase while you are working.
if you mean literally forcing people to only be able to modify a file they are tasked to work on, not only is that counterproductive when in a good team, but just pretty pointless in general when the person working on the branch can just ask about what they should be doing.

at the end of the day, git and other scm's are tools, and if they are used incorrectly bad things will happen. it is up to the team leader and members to make sure they are all doing their respective jobs and not stepping on any toes, and if they do make sure they ask first.

I have some light dev team experience in a few different environments and development strategies. in all of them but one, the project lead followed the strategy, we got tasks, and everyone was happy.
one of the more popular I've seen and the one I have most experience with in my work is kanban, where you use things like trello or zenhub to keep track of specific features and where they are on the timeline.

>>61959993
cont. kanban: eg., there are 6 columns: ideas/todo, tasked, working, testing, done, and deployed. when a feature is approved to be added to the first column, in some workplaces you will have the freedom to pick a task to work on, while in others you will be assigned one based on your previous experience by your manager/leader. when choosing your own task, you will probably be asked to estimate how long the task will take to complete in work hours. the task will be moved to the assigned column (if your team has this) when waiting on approval. if you are given the green light, the task will be moved to the working column and you will begin development in a new branch and keep track of how many work hours are allocated to it. once it gets done, you move the task over to the testing column, where you run all unit tests/finalize any more tests you had to make to test the feature. once all tests are passed, you move it to the done column, and it will be reviewed by your QC/PR/etc teams, and once everything is good the branch can be merged. as long as you didn't change anything you were not tasked with, you should have no issues merging; at worst there will probably be some small changes someone else made, either to add some API feature or to fix bug(s) squashed in master. (ideally, you should be merging bugfix commits into your own branch, and keeping up with master if you want to; but often it's easier to work on what you know unless master is moving really fast).

quick_rundown.jpg

something I forgot to mention was that you should keep in mind merges can happen between any branches, with any number of commits; if you are working on your own branch, it may be beneficial to merge master or other changes back into your own branch to make sure all the code you're writing actually works with current changes.