git - do you 'pull' before/after switching branches?

[David Schwartz 426]

Here at work we're advised to do a 'git pull' frequently throughout the day, and especially before and after switching branches.

 

I guess this is because we've got a lot of quick-turn work rather than long-term dev work.

 

Does anybody else do that?

[Sherlock 663]

You can pull anytime you feel you need to update your local repository. This does not change what you are currently working on. It is however frowned upon to push your work without pulling and merging recent changes into it. But that might depend on team size and individual work flows.

[Gustav Schubert 25]

Sometimes I opt to have two local repositories, one which is connected to a remote, and another one which is not - which is the one I will use for development. I know which is which by folder name.

 

When I open the one with connection to remote in Visual Studio Code (folder), it tells me that there is new stuff that I can pull down, and I will, immediately.

 

When I want to publish some work I will use my merge tool to copy the new stuff over to the hot repo and then commit with a button click.

 

( It is via my merge tool that I keep in control, it works with directories on disc. )

 

You could have two repos connected to the remote, pull one often - as advised, and the other one only when you want (after a successfull push, from other repo).

 

( If the repo is large you can care about subfolders only and ignore the rest, only merge the subfolder you are working on. )
 

[Anders Melander 1779]

51 minutes ago, Gustav Schubert said:

Sometimes I opt to have two local repositories, one which is connected to a remote, and another one which is not - which is the one I will use for development. I know which is which by folder name.

What problem is that supposed to solve?

[haentschman 92]

Quote

What problem is that supposed to solve? 

+1 ???

[Anders Melander 1779]

2 hours ago, Sherlock said:

It is however frowned upon to push your work without pulling and merging recent changes into it. But that might depend on team size and individual work flows.

I don't think you can push unless you're on the tip of a branch. Your changes would overwrite the changes made between your current commit and the remote tip.

I guess the remote could do an automatic merge but would that then be made in a new commit or would it alter the commit you made? Doesn't seem likely.

[Gustav Schubert 25]

1 hour ago, Anders Melander said:

What problem is that supposed to solve?

1) Because for me there is no better was to see what has changed.
2) When learning how to use git. I don't want to do that live at github.
3) I also have different settings for .gitignore
4) My local only one has a longer history, I want to keep that

Edited September 23, 2020 by Gustav Schubert
3 and 4

[Sherlock 663]

10 minutes ago, Gustav Schubert said:

1) Because for me there is no better was to see what has changed.
2) When learning how to use git. I don't want to do that live at github.
 

1) That is what a diff tool is for.

2) Of course learning should be done with your own repository and your own server. But learning should also involve avoiding wrong uncomfortable patterns. And what you are doing is simply a waste of time and space. Everything you want to accomplish can be done with your first repository alone.

[Gustav Schubert 25]

11 minutes ago, Sherlock said:

Everything you want to accomplish can be done with your first repository alone.

In theory, yes. But I have difficulty to compare branches with only one folder. My merge tool which is my diff tool needs two folders. And, I have more branches at home than I have at github.
 

[Dalija Prasnikar 1393]

12 hours ago, David Schwartz said:

Here at work we're advised to do a 'git pull' frequently throughout the day, and especially before and after switching branches.

 

I guess this is because we've got a lot of quick-turn work rather than long-term dev work.

 

Does anybody else do that?

If I am working on a repo in a team then I pull often, otherwise, no - because I know there is nothing to pull 

 

How I use Git (modified git flow)

• I almost always use GUI client - SourceTree - it was best client on OSX at the time, and I got used to it, so I am using it on Windows, too. It has its quirks (every client has) but I never shoot myself in the foot with it
• master is always production ready
• develop is development branch 
• both master and develop live on remote (and they are the only ones that live on remote)
• each feature is new branch, usually very short lived - never pushed on remote, unless they live too long and have to be shared for some reason, but for that I use temporary remote

Basic workflow (if working on team)

• before creating feature branch pull from remote (there will be no merges, because repo is clean - also, I always do pull with rebase)
• create feature branch from develop
• a) work on branch, commit...
• b) if I think there is something new in the repo and I have committed all my feature branch changes, switch to develop and pull with rebase, same with master 
• c) if there were changes rebase feature branch on develop, check if everything works - repeat from a)
• when work is done on feature branch, pull and rebase feature on top of changes (if there were any), check if it works (if checking takes long enough and depending on potential conflicts with others, pull again, rebase... check...) when all is completed merge feature branch to develop and push to remote

 

If you have problems with workflow, you can setup demo repo and use that to figure out optimal workflow and then apply to real one. 

 

If you ever feel like you have messed up something locally, rename (or otherwise backup files you have been working on) repo folder, clone from remote, create new feature branch and copy your changed files back.

 

I said it before, but it is worth repeating. Unless you are GIT DIE HARD, don't use console.

[haentschman 92]

Hi...

Quote

My merge tool which is my diff tool needs two folders

which you use?

 

Edited September 23, 2020 by haentschman

[Dalija Prasnikar 1393]

I forgot another extremely important thing. I never commit everything blindly, I always check every change before commiting to avoid accidental errors and changes in files that should not have been changed.

[Fr0sT.Brutal 899]

54 minutes ago, Gustav Schubert said:

3) I also have different settings for .gitignore
4) My local only one has a longer history, I want to keep that

All this could be achieved with branches inside single repo. You can develop in 'private' branch then merge with squashing to 'public' one that will be pushed to Github or whatever.

[Sherlock 663]

1 hour ago, Anders Melander said:

I don't think you can push unless you're on the tip of a branch. Your changes would overwrite the changes made between your current commit and the remote tip.

I guess the remote could do an automatic merge but would that then be made in a new commit or would it alter the commit you made? Doesn't seem likely.

IIRC pushing something not from tip will just open a new branch... but that might also be an optional setting.

[Anders Melander 1779]

We also do all work in feature branches but our branches are always pushed to remote (and for this reason alone we almost never rebase).

We need to have the branches on the remote for several reasons; There are mostly more than one person working on a feature and they need to have access to each others changes. Of course it's up to the individual if they want to create local branches of the feature branches and do their work in those. Personally I just stash and only push when I have something that I know will build. We also to have the branches on the remote in order to have the build server run unit- and integration tests on them. Finally when work on a feature branch is complete we create a pull request to have it merged into the main branch. When QA have tested the build, which they've grabbed from the builder server, someone performs code review on the changes and only then is the PR allowed to be merged into the main branch.

[Rollo62 534]

2 hours ago, Dalija Prasnikar said:

I forgot another extremely important thing. I never commit everything blindly, I always check every change before commiting to avoid accidental errors and changes in files that should not have been changed.

Just to clarify that.   What do you mean excactly by "check every change" ?

I usually make changes, check compile, and decide more or less depending on the amount or complexity of changes
or their locigal completeness, if I commit or not.

If you mean to commit only code that compiles, yes I do the same.
Or do you mean to commit only after complete tests, UnitTests etc.  ?

 

There are some voices in the web that recommend to commit every little step in GIT very frequently, as a kind of "undo" function,
but I'm not working that granular yet.
I always tried to do more commits, but my reality is that I commit more complete logical tasks,
which are more like medium or larger transactions in code.

 

What level of granularity do you recommend for commits in your note above ?

 

 

 

[Dalija Prasnikar 1393]

2 hours ago, Rollo62 said:

Just to clarify that.   What do you mean excactly by "check every change" ?
 

That means going through diff list and making sure that all changes are expected changes - changes I intended to make (that does not mean I am rereading every line of code).

 

For instance, first step is making sure that only files that had to change are changed - for instance if I am making changes in for code and I am not touching design and dfm (fmx) file pops in changed files, I will not commit those files and will revert changes after quick inspection.  Next I will go through changes I expect and I did make. If I was working on class xyz and something is also changed in abc, well that means something is wrong. Such things don't happen often, but sometimes you mess things up during debugging or leave unwanted artifacts.

 

2 hours ago, Rollo62 said:

What level of granularity do you recommend for commits in your note above ?

 

I don't commit every two lines of code, but logical tasks. If the task is larger, then it can be spread through several commits. 

 

[Anders Melander 1779]

2 hours ago, Rollo62 said:

What do you mean excactly by "check every change" ?

You should examine the diff of your changes before you commit them instead of just committing all files that has changed.

Practices differ but for example when I have made a change to a form I only commit that specific change - and directly derived changes. All the Explicit* and Original* fluff that the IDE changes are left out. Also adding a file to a project usually result in 40-50 changes (relating to platforms I haven't even installed) of which only one or two need to be committed.

[Lars Fosdal 1790]

It is good practice to pull / update, CHECK AND COMPILE before push / commit.

 

I agree with Dalija and Anders that if there are unintended cosmetic changes in a commit (explicit form coordinates / white space), it is good practice to discard the changes before the commit.  That really simplifies looking for actual changes in the version history later.

And - for the love of developer team sanity - write proper push / commit statements 😛
Edit: To clarify - comment the scope and purpose of the changes. If there are caveats, they should be comments in the code, not in the commit.

[Guest]

14 hours ago, Anders Melander said:

You should examine the diff of your changes before you commit them instead of just committing all files that has changed.

For smaller "personal" projects, that is the only use i have of version control. Living without these "checks" i remember was hellish.

[Anders Melander 1779]

29 minutes ago, Dany Marmur said:

For smaller "personal" projects, that is the only use i have of version control.

Sure. For personal projects I rarely use branches at all. It's only when I start on something that I'm not sure I will end up using in the end (e.g. experiments) or some feature that will take so long to implement that I don't want it interfering with whatever else I'm working on) that I use branches.

But even for personal projects it's good to be able to go back in time to find out what what you did that broke something. Sometime you can even use the commit message to clear up why some piece of code is there in case you forgot to document it properly with comments in the code. You could say that the individual code comments document the tactic while the commit message document the strategy. Of course it would be best if the code comments did both but we're not all super humans.

[Mike Torrettinni 198]

On 9/23/2020 at 8:09 AM, Dalija Prasnikar said:

I forgot another extremely important thing. I never commit everything blindly, I always check every change before commiting to avoid accidental errors and changes in files that should not have been changed.

I find this very valuable! I was only checking commits at the beginning, learning git and git tools, then I stopped - I believed if feature is done and it compiles it should be ready for commit.

Well, after reading this statement, I started checking the changes about to be committed, and soon I noticed that when working on multiple units I forgot to delete debugging or temp stuff. Or I noticed something is implemented odd and should be improved, something I wasn't focused on at the dev time.