Ana is learning

Learning Git

April 13, 2019

git branches

Backstory: Recently, I’ve started a new job where I am going to learn a lot of new things, and therefore I want to keep track of, at least, some of them.

My normal Git workflow was (and still is when I am working on my solo projects) really basic, without any conflicts.

  • I would start by either cloning an existing repository - git clone name_of_the_repo.git or creating a new one with git init
  • run git pull origin master before doing any changes just to be sure that everything is up to date
  • create a new branch so that I don’t mix things on master git checkout -b name_of_the_branch
  • after I’m happy with my changes and I’m ready to push them, I would run a git status, just to see exactly all the files that were changed
  • I would usually run a git add ., adding all the changes (including removing an existing file or creating a new one)
  • afterwards, I would commit my changes with git commit -m'Some explanatory message about the changes
  • finally, I would push my branch with git push origin name_of_the_branch

And that was basically everything. I would then merge the branch to master from GitHub and delete it afterwards.

The new workflow is not very different but there are some small details that I have to take into account. These are:

  • when adding changes, if there are many (although, the best thing is to try and keep it in small commits), I would do git add -p(p stands from patch). This will open an interractive window and you’ll have to go through each change and decide if you want to keep it or not (there are some other options like manual editing)
  • if I want to commit some other change to my last commit, without providing any message, I run git commit --amend --no-edit
  • after pushing the branch, I will have to rebase using git rebase -i origin/master(i stands for interractive). This will open an interractive window, where I see all my commits and I’ll have to chose what to do with them. The default option is pick, which basically means to leave everything as it is. Another one is squash, which is used if I don’t want to have a long log history so it’s squashing the commits
  • sometimes, if other people worked on the same files like I did, there will be a merge failure conflict so I’ll have to run git rebase --continue, which will lead to a selecting screen between the changes (the ones that I made and the ones that other people made), where I will have to select which one to keep (don’t forget to stage the changes here!). I run this command multiple times until everything is all right
  • after running a rebase, I will run git push (sometimes, it might need to be git push --force if, for example, I squashed some commits)

Other things to take into account is that the interractive mode is usually opened in VIM, which can be quite scary (it took me a while to figure out how to exit, lol), so here is a cheatsheet.


Ana Filote

Ana Filote Self-taught front-end developer. Trying to learn new things.