16

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)

Comments
  • 4
    I think u missed git merge
    The highly conflicting topic!
  • 0
    @Nawap you mean to merge two branches locally and then push to GitHub?
  • 2
    Yes !
    Exactly, the same
  • 11
    The part where you fuck up a branch and start copying wild commands you found on google
  • 0
    @Kimmax I don't follow?
  • 3
    @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
  • 1
    What do you man by "Digital Signature Mapping"? It might sound confusing to a git beginner
  • 7
    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.
  • 0
    @hawkes yea.. even i got confused.. noted will change...
  • 0
    @k0pernikus noted all points... I'll need to go through rebase.. but.. do you think rebase should be covered in an introductory session?
  • 0
    @ArcaneEye seriously dude.. I can't understand what do you mean to say
  • 2
    @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 😐
  • 0
    @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
  • 1
    @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.
  • 0
    @k0pernikus now I am scared about rebase
Add Comment