Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Kimmax111097yThe part where you fuck up a branch and start copying wild commands you found on google
-
Nawap13987y@dextel2
Yup u get so many conflicts while merging two branches to one.
So to resolve the conflict u randomly copy cmds from internet
I think u should have come across this gif ,it's self explanatory
https://goo.gl/images/2K9ksH
Sorry gif is not uploading -
hawkes15727yWhat do you man by "Digital Signature Mapping"? It might sound confusing to a git beginner
-
Make sure your juniors understand git != GitHub and that they could use any other frontend for it like bitbucket, gitlabs or the git own server.
They shouldn't use a gui in the beginning, but use the command line to understand what is happening. Gui can be nice in everyday's work but it can abstract too much away
Don't let them get away with `git add .`
Make them understand that git is decentralized and any checkout could serve as source of truth if deciced.
Show them the awesomeness of git stash / apply.
Teach them the weirdness that is revert commits and that you if you revert a merge, you cannot merge anew but you also have to revert the revert commit. (This aspect gave some of our experienced developers headache.)
Rebase. It's powerful. They should know about it. (At least show them git pull --rebase) Don't scare them though the dangers should be made clear. Since you also want to show amend it's clear you are open to changing the history. -
@k0pernikus noted all points... I'll need to go through rebase.. but.. do you think rebase should be covered in an introductory session?
-
blem1410677y@k0pernikus indeed, there should be "0. git != GitHub".
A while ago I had to introduce trainees to project and told them to "install git". Came to GitHub installed and they were confused why I was not happy. Also when few weeks later I asked them to make their own trainee git repo on dev server and copy project repo (non-writable for them) there they thought I ment public GitHub repo 😐 -
@blem14 that's the exact reason I want to educate juniors..I myself am not a pro in git and I cannot see juniors in shoes by the same age I am...
I blame our beloved education system for this... If it was up to me.... I'd make git a mandatory subject -
@dextel2 Rebase should not necessarily be part of introduction section esp. since it's only one day. I've seen people struggle with the bacis of git, so it may be prone to confuse them.
(Understanding git will take them longer if they know subversion before 😉)
That being said it would suffice imo to point them to the advanced features for them to look up themselves. So you should mention it, state why it can be useful, but not go into deep depth.
It also depends what git workflow you want to establish. In some projects I was forbidden to force push anything. In others, the pull request was only accepted if all my commits were squashed into one.
If you don't want to go into the depths of rebase, all I ask it that you do not scare them about that feature. I've seen a lot of developers get sweaty hands when I told them to rebase their feature branch against the main branch. I have to walk them through it.
It's like as if they were told to NEVER do that.
Related Rants
So I am conducting an introductory seminar on git and GitHub for juniors and as per my knowledge I've drafted this outline, please add your inputs..
The seminar will be of 1 day only
1. Install and configure Git and Github
2. Digital Signature mapping
3. Git init
4. New Project with HTML
5. Configure remote (git remote add <origin> <url>) ends with .git
6. Git commit (git commit –m “Title” –m “commit message”)
7. Pushing git push (git remote push origin master)
8. Git commit –amend
9. Git pull (git pull origin master)
10. Git checkout (git checkout –b new_branch_name)
11. Do some changes
12. Git push new branch (git remote push origin new_branch_name)
13. Git switch branch (git checkout <name_of_existing_branch>)
14. Pull requests
15. Git log (git log –oneline –graph)
question
seminar
git
github